MDM approval workflows: how they actually work, and what skipping them costs

Most teams leave the approval workflow unchecked. There is a setting — “Require approval for changes” — and it stays off. The tool supports it, but it seems like overhead. Governance can come later, once the system is running and people are comfortable with it.

Later tends to arrive after something breaks. A product code gets changed without notice and takes down an EDI feed. A supplier's bank details get “corrected” by someone who should not have touched them, and the next payment goes to the wrong account. A cost center is retired in the MDM system, but the teams still booking to it were never told.

Approval workflows are the mechanism that prevents these things — when they are configured for what actually goes wrong, not bolted on as a checkbox.

What an approval workflow actually does

An MDM approval workflow is a staged change process. Instead of editing a record and saving immediately, a user proposes changes inside a changeset — a container that holds every pending edit until a reviewer acts on it.

The reviewer sees every field that would change, side by side with its current value, across every affected record. They can approve the whole changeset, which commits all changes atomically to the live records, or reject it with a note explaining what needs to change before resubmission.

Nothing touches live data until the changeset is approved. That is the point: the change is visible and auditable before it has any downstream effect.

This is different from access control, which prevents unauthorized users from opening the edit form at all. Approval workflows handle the harder case: a user who has legitimate edit rights, but whose changes still warrant a second pair of eyes before going live.

The scenario that makes the risk concrete

Supplier bank details. Someone submits a change to a supplier's account number. The reason given: the supplier switched banks. Plausible — this happens all the time. Without a review step, the change saves immediately. The next payment run goes to the new account. If the change was legitimate, no problem. If it was not — if a social engineering attack got someone in your organization to “update the details” — that payment is gone.

Payment redirection via master data manipulation is well-documented. Organizations that have been hit describe the same mechanism: someone with legitimate edit access made a change, it went live automatically, and nobody else saw it before the payment ran.

An approval workflow does not eliminate this risk entirely — a compromised reviewer is still a problem. But it adds a required second review on a high-stakes change before money moves. That is a real control, not a theoretical one.

Why most implementations fail anyway

There are two failure modes, and they are opposite problems.

The first is skipping it entirely — no approval step for anything. We have covered why that is a problem.

The second is applying approval requirements to everything. Every field change — including a product description correction or an address update — requires two-day approval. Data stewards route around the system. They make changes in the source ERP directly, or they stop updating data at all and let it drift. The MDM system becomes the record of what data used to look like.

Reviewers have it worse. A queue of 300 low-stakes changesets trains them to approve without reading. When the high-risk change arrives — the bank account update, the product code rename that will break three downstream integrations — it looks exactly like the others. Click approve, move on.

Governance theater is harder to fix than no governance, because everyone believes the controls are working.

Matching workflow complexity to actual risk

The fix is a deliberate decision about each entity: what level of control does this data actually need?

Low-risk entities are not ungoverned. They still have validation rules, role-based access, and a full audit trail. The approval step is one control among several — reserve it for situations where it adds real value rather than applying it everywhere because it feels thorough.

The changeset model in practice

In Primentra, approval workflows are configured per entity. An entity either requires approval or it does not. When enabled, every edit goes through a changeset before it can be committed.

The changeset review screen shows current value and proposed value for every changed field, across every affected record, in one place. A reviewer does not need to open individual records to understand what is changing — the comparison is right there. Approve and the entire set commits. Reject and the proposer receives a note explaining what to address before resubmitting.

The audit trail captures who proposed the change, who reviewed it, when each action happened, and what the record looked like at every stage. If something breaks downstream three weeks later, the trail tells you exactly what changed, who initiated it, and who approved it.

For teams coming off Microsoft MDS, the changeset concept is familiar — MDS had staging tables that served a similar staging purpose. The difference is that the review interface shows the full before-and-after comparison without requiring a developer to write the query and interpret the results.

Frequently asked questions