Approval Workflows
An approval workflow adds a review step before a data change becomes permanent. When an entity has Requires approval enabled, a save does not write to the master data. It creates an approval request that an approver must decide on.
Watch the whole workflow in four and a half minutes β the Approver flag on the role, the entity settings, a steward's submission and the owner's decision:

What approval changes
Without approval, Save writes straight to the entity. With approval, the same save creates one approval request that holds every change in that save. The grid keeps showing the approved data. Your changes stay in the queue until someone decides on them.
Who may approve
Approval rights work in two layers. Both are needed. Read, write and delete permissions play no part in them.
- Role flag β a role has an Approver checkbox ("Can approve changes and requests"). Every member of that role becomes eligible to be an approver.
- Entity assignment β an eligible user must also be assigned as an approver of that specific entity, in Access Management β Entities.
A user may decide on a request when both layers apply. See Configuring Approvers for the settings, and Roles & Permissions for the role flag.
What happens when you save
- You edit cells in the data grid and click Save.
- The Submit changes for approval modal opens instead of the normal save dialog.
- You check the summary, add an optional note, and click Submit for approval.
- The modal confirms the submission and shows the request number.
- Each assigned approver with email notifications on receives a mail.
All changes in one save become one request. An approver decides on the whole request, not on single records. This keeps a set of related edits together.
What the grid shows
The grid always shows the approved data. Pending changes are never mixed in. A record with a pending change is marked and locked:
- The row gets a diagonal hatched background and a gray left border.
- A lock icon replaces the row checkbox.
- The cells cannot be edited until the request is decided.
A record you marked for deletion is shown in red with a strikethrough and a red lock, until the request is approved.
Where approvals live
Two pages in the settings sidebar, under Approvals & Submissions:
| Page | URL | Who sees it |
|---|---|---|
| My Approvals | /admin/approvals | Users with the Approver role flag, and administrators |
| My Submissions | /admin/my-submissions | Every user |
Notification bell
The bell in the header is color-coded. The badge shows the total count.
- Red β one of your submissions was rejected, or there is an error notification
- Orange β requests are waiting for your decision
- Green β one of your submissions was approved
The highest priority wins: red, then orange, then green. Click an entry in the dropdown to open the matching page.
Dashboard widgets
The dashboard has two approval widgets. Both link to the full page.
- Approvals β approvers only. The most recent requests in all statuses, with a "N pending" badge.
- My submissions β your own requests, newest first, with a display count you can set.
Keeping the history small
Decided requests stay in the database. Set a retention period to remove them automatically. See Data Retention.
Related
- Configuring Approvers β turn approval on and assign the approvers
- Role: Submitter β submit changes and follow their status
- Role: Approver β review a request and decide
- Rules in Approval Workflows β how business rules refuse an approval
- Data Retention β how long decided requests are kept