Your approval workflow only works if every door respects it

We switched “Requires approval” on for a supplier entity, the way the settings screen and the help page both describe, and edits in the grid went to a queue exactly as promised. Then we sent the same write through the REST API. It went live in under a second. No queue, no approver, no record that anyone had bypassed anything. The setting was on. It was only ever on for one door.

This is what happens when a governance feature gets built against the interface someone is looking at, and never checked against every other way data can arrive: it works exactly where you tested it, and nowhere else. We fixed it in version 1.2026.8.23. Here is what we found checking each route, and the one route we decided, on purpose, to leave open.

Five ways data reaches an entity. Four respected the setting.

The grid checked the setting because the grid was where approval workflows were built and tested. The REST API, added later, wrote to the same tables through a different code path and simply never learned the rule existed. A file import worked the same way. Neither was a deliberate decision — both were the setting quietly applying to less than the name promised.

Two of the fixes were sharper than “now it queues.” A delete through the API used to apply immediately on an entity that requires approval — the grid had always turned Delete into Mark for deletion, a queued and reversible request, but the API had not, so the one write nobody can undo was guarded by the browser and nothing else. And business rules used to be checked only when an approver applied a change, not when it was first submitted, which meant a blocking rule failure landed on the approver, who had never typed the value and had no way to fix it. Both are checked at submission now, on every route.

Why staging is the one route left open

It would be tidy to say every route now respects approval, but that is not true and we are not going to write around it. A scheduled load into the stg schema still publishes straight to the database on an entity that requires approval, every time.

The reason is not that staging is automated. The REST API is automated too, and the API is now fully covered. The difference is that staging has no user. A feed running at three in the morning has nobody to email and nobody standing behind it who could meaningfully second-guess the system sending the data — putting that load in a queue does not add a review, it just adds a wait, and within a week somebody switches the setting off to make the wait go away. That leaves you with less governance than before, not more.

So the rule ended up as one line: every route with a user offers that person’s change to an approver first. Staging has no user, so it cannot. What it gets instead is a full record — every batch shows up in batch history and the audit log, so what a load changed is always traceable afterward, even without anyone having reviewed it first. Approval prevents. An audit trail records. Staging keeps the second and gives up the first, and that trade only makes sense if you know you made it. If an entity cannot tolerate that, the fix is to keep it out of staging, not to hope nobody notices.

The question worth asking any vendor, not just us

“Does it support approval workflows” is a checkbox question, and every MDM and PIM tool answers yes to it. The question that actually tells you something is narrower: does the setting apply to every way data gets in, or only to the screen the demo shows you? A tool built for one interface and bolted onto an API afterward tends to get this wrong in exactly the shape described above — the review queue is real, it is just optional for anyone who does not use the UI, which in practice means it is optional for the migration script, the nightly integration and the colleague who found the API docs.

Worth checking in your own stack, whatever you run: does a bulk import respect the same setting as manual entry, does an API write get queued or does it just succeed, and does a scheduled feed have an explicit, stated exception — or an unstated one nobody has gone looking for yet.

Common questions

For the full mechanics of how a request moves from submission to a live record, see how Primentra’s approval workflow works. For what the REST API covers beyond this fix, see the REST API overview.