How Primentra's Approval Workflow Works: From Edit to Live Data

Someone on your team edits a branch record. Types the wrong region. Clicks Save. The change lands in your master data in seconds — and within minutes it's flowing into your ERP, your reporting dashboards, and everything downstream. By the time you catch it, you're untangling bad data across half a dozen systems.

Approval workflows stop that. Nothing commits to your live master data until an approver has reviewed the change and signed off. Changes sit in a staging area first. An approver checks the diff. Only then do they commit. For context on the broader data model these workflows protect, models, entities, and attributes explains how Primentra structures master data.

Here's the full picture — what happens between "Save" and "live."

1. Editing works the same way — the difference is at Save

Editors don't work any differently because an entity has approval enabled. They edit cells in the data grid as usual — create records, update fields, mark rows for deletion. The change summary at the top of the grid shows what's pending: 1 new, 1 edit, 1 deletion.

The difference kicks in when they click Save. Instead of a simple confirmation, a Submit for Approval modal appears. It shows the complete list of pending changes, the approvers who will receive the request, and an optional note field for context. One click submits.

One important thing to understand: approval is always about a complete save operation, not individual records. If the editor changed six records before clicking Save, those six changes are submitted together as a single approval request. The approver reviews the whole batch and either approves or rejects it as a unit. You can't cherry-pick which records to approve. This is intentional — partial approvals would leave the data in an inconsistent state.

2. Changes go into staging — not live data

When the editor submits, the changes don't touch your live master data tables. They go into a separate pending changes table — a staging area — and wait there. The data grid keeps showing the approved, committed values. The only visible sign is a small lock icon on rows with pending changes.

That lock matters. While a record has a pending change, nobody else can edit it. No conflicting changes pile up on the same record.

3. Approvers are notified immediately

The moment a change is submitted, Primentra emails all configured approvers and updates the notification bell in the navigation with a badge count. Approvers land on the Approvals screen — a dedicated page accessible to anyone with approval rights.

The screen has two tabs. My approvals shows changes waiting for your decision. My submissions shows the status of changes you submitted — pending, approved, rejected, or returned. Each request shows the entity type, a request number, the submitter, the date, and a change count broken down by type: new records, edits, and deletions.

4. The review panel shows a complete field-level diff

Clicking Review & Decide opens a full review panel. Changes are grouped by type — New, Edit, Delete — and each record shows a field-level diff: old value and new value, side by side. Only changed fields are surfaced prominently; unchanged fields are collapsed.

For deletions, the panel shows a cascading effects warning when other records reference the one being removed. If deleting a branch clears the Branch field on four zone records downstream, the approver sees that before making the call.

Approvers can flag individual rows for revision — marking specific records as problematic while leaving the rest clean. These flags feed directly into a Return decision, where the editor sees both the overall reason and per-row comments.

If other approvers have already looked at the same request, the panel shows their decisions in a Colleague decisions panel — who approved, who rejected, who hasn't responded.

5. Three outcomes: Approve, Return, or Reject

After reviewing the diff, the approver makes a decision:

Bulk actions handle the easy cases: Approve all or Reject all when the whole batch is clearly fine or clearly not.

The revision loop — v1, v2, v3

When a change is returned, the editor sees the feedback on the My Submissions tab: the approver's written reason and any flagged rows with per-row comments. They fix the issues and resubmit, which creates a new version of the request.

The review panel keeps the full version history. When an approver looks at v2, they can expand a collapsible section to see the v1 rejection reason, the original values, and a side-by-side diff of what changed between versions. The context is all in one place — no digging through emails to understand what was fixed.

Who can approve

Approval rights work in two layers, set up independently.

Layer 1 — Role eligibility. Each role has a Can Approve flag. Enable it, and every member of that role becomes eligible to be assigned as an approver. This flag is completely independent of Read and Write permissions — a user doesn't need any CRUD access to an entity in order to approve changes on it.

Layer 2 — Entity assignment. Each entity has an Assigned approvers list. An admin explicitly picks which eligible users can approve changes to that entity. Only assigned users get notified when a change is submitted and can make the Approve / Return / Reject call. The picker only shows users who are members of a role with Can Approve enabled — everyone else is invisible there.

So the full rule is: Can Approve on the role makes you eligible. Being in the entity's Assigned approvers list makes you active for that entity. Both conditions need to be true.

The 4-eyes principle — and when to turn it off

By default, nobody can approve their own changes. If you submitted it, someone else has to sign off. This is the 4-eyes principle — required by most data governance and compliance frameworks.

If you have a case where self-approval makes sense — say, a senior data steward who needs to push urgent corrections without waiting — you can enable Allow self-approval per entity. It sits in the entity configuration and applies to all users with approval rights on that entity.