Amendments
How supported changes to authorized records remain separate until approval.
An amendment is a controlled proposal to change an already authorized record. It allows the live record to remain usable while the proposed change moves through maker-checker.
Amendments are available only for registered entity types and supported fields. The presence of maker-checker on initial creation does not automatically mean that every later field can be amended.
Amendment intents
| Intent | What remains live while pending | What final authorization does |
|---|---|---|
| Update | The current authorized field values. | Applies the approved proposed values. |
| Delete | The active authorized record. | Soft-deletes or disables it through the registered lifecycle. |
| Restore | The inactive or deleted record. | Restores it through the registered lifecycle. |
Delete and Restore are available only for entities that explicitly support those lifecycle intents. They do not accept proposed field changes.
Deletion dependencies
Deleting a record does not erase its history. Where deletion is supported, remoteEaze retires or soft-deletes the record through its controlled lifecycle.
The system checks known dependencies before a deletion proposal is created and checks them again before final authorization. If another record still depends on the target, the deletion is stopped and the message identifies the dependency that must be resolved first. For example, a configuration value in use by an Account, Product, policy, or operational record cannot be retired until that use has been removed or replaced.
The exact dependency checks depend on the entity. Do not assume that Delete is available merely because the user has Delete permission. Permission allows the attempt; the record's current relationships determine whether it is safe to complete.
Permissions and scope
Amendments reuse the target entity's permissions:
- reading an amendment requires Read on the target entity;
- proposing or submitting an Update requires the target's Update permission;
- proposing or submitting a Delete or Restore uses the target's Delete permission;
- approval, rejection, and denial require the target entity's exact current L1, L2, or L3 authority;
- tenant and data-access scope are resolved from the target record.
There is no independent “amendment role” that bypasses access to the target.
Amendment lifecycle
- An authorized record is edited through a supported amendment form.
- remoteEaze records only the permitted proposed fields and shows the current and proposed values in the amendment panel.
- Submission uses the required approval count resolved for the target action.
- Checkers approve, reject, or deny the amendment through the standard maker-checker sequence.
- On final authorization, remoteEaze applies the proposal and records when it was applied.
If zero approvals are required, submission authorizes and applies the amendment directly.
Correction and concurrency rules
Only one pending amendment may exist for the same target record. A second proposal is blocked rather than silently replacing work already under review.
The amendment creator can edit or discard it while it is Captured or Rejected. A rejected proposal can be corrected and resubmitted by its creator. Other users cannot take over that correction merely because they have Update permission.
As with other maker-checker records, the creator or last modifier cannot make the checker decision on their own proposal. Denied is terminal.
What users see
On a supported detail page, the amendment panel identifies whether an update, deletion, or restore is pending, shows its status, displays the field-level differences for updates, and presents only the workflow actions available to the signed-in user.
Until final approval, reports and operations continue to use the currently authorized target values, not the proposed values shown in the amendment.