When two people work at once

You create a draft on a role. While it waits for approval, a colleague changes the same role and her change is approved. Your draft now describes a state that no longer exists — and publishing it would overwrite her work.

That is exactly what used to happen, silently. Neither of you would have found out.

How you notice

Every draft remembers the state it was created from. If that state has moved on since, you see it in two places — both before you click Publish:

In the draft list the row carries an icon with the note “Base out of date”.
In the detail pane a card above the actions reads “The base has moved”.

The wording distinguishes two cases, and the difference matters:

Wording	Meaning
“Publishing is refused until the change builds on the current state.”	The attempt fails. You need to act.
“Publishing proceeds, but would overwrite the newer version.”	The attempt goes through. The decision is yours.

Which one applies depends on a setting for your tenant (see below).

What you can do

Look at what changed. The element’s history shows the change that landed in the meantime, with its reason and approval.
Discard your draft if the other change already covered your concern.
Start over: discard and create a new draft on the current state. The new draft automatically gets the current base.
Talk to each other. For a genuine substantive disagreement that is the right route anyway — the platform deliberately does not decide such cases itself (see below).

What the platform does NOT do

It never merges automatically when both of you changed the same field. Different fields could be merged; for the same field every choice is a substantive decision, and a human makes it. An automatic “last one wins” would be exactly the silent overwrite this feature abolishes.

It never treats a draft without a base as a conflict. Two cases look identical from the outside: creating an element for the first time (there is no history yet) and a draft that existed before this check was introduced. Both pass through unchanged — no existing draft becomes unpublishable because of this feature.

It never halts anything because of its own error. If the current state cannot be determined, publishing proceeds. A check that blocks on its own failure would, in case of doubt, bring the whole organisation to a stop.

Scenarios: all or nothing

A scenario bundles many changes into one decision. Before the first of them is written, the platform checks all of them — the change base and the approval — and names all affected drafts, not just the first. Otherwise you would have to work through them one at a time and need as many attempts as there are conflicts. If even one change is blocked, none is applied.

One limit belongs with that: a change that only fails a validation rule while being written is rolled back for itself — the remaining changes of the scenario stay applied. This gap is known and still open; closing it requires rebuilding the publish path, not another up-front check.

More on the scenario as a proposal: Scenarios and Collective Proposals.

For administrators: the three stages

The check is introduced in three steps, deliberately. A false positive would prevent every publication — so first measure, then switch.

Stage	Behaviour
off (default)	Recorded but not checked. After deployment nothing behaves differently.
observe	The conflict is detected, displayed and logged — publishing proceeds. This shows you how often it actually occurs.
enforce	The conflict prevents publication with a clear message.

Switched via the environment variable FLAG_MERGE_BASE_CHECK (off / shadow / enforce); the setting applies from the next start and propagates automatically to cell installations. Measure on shadow first, then move to enforce.