What Happens When Two Admins Save the Same Record in EDGEBIC

EDGEBIC uses a last-write-wins contract: if two people save the same record within the same window, the second save overwrites the first silently, with no exception and no warning. In EDGEBIC by User Solutions this is a deliberate design decision rather than a gap, and knowing it changes how a multi-user plant divides ownership of master data. This post explains what actually happens, why it works that way, and the three working rules that make it a non-issue.

The wider multi-user picture is in moving from single user to a shared server. This post is the one behavior of a shared database that surprises administrators.

What Actually Happens

Two supervisors, Alice and Bob, both open the same work center. It currently reads a maximum batch size of 50 and an efficiency of 85 percent.

Read the last row carefully. Bob did not touch the batch size, and yet it is back to 50. His save wrote the whole record as he had it loaded, and his copy still carried the old batch size. Alice's change is gone. No error appeared for either of them. Alice will not find out until she opens the work center again, which might be next week.

That is the contract, stated plainly: the last save wins, the loser is not told, and the loss is a field the winner never intended to change.

Why It Works That Way

The obvious alternative is to reject the second save: check whether the row changed since it was loaded, and refuse if it did. That approach was tried and produced a worse problem.

Any write that touched a row outside the current screen (an import run, a scheduler persist, another part of the application) made the check fire on saves that were perfectly valid. The routing designer hit it repeatedly. A user who is told "somebody else changed this, your save was rejected" when nobody did loses trust in the software fast, and the workaround they invent is to save twice.

So the contract is deliberate. In a plant where a handful of named people own distinct areas of master data, a rare silent overwrite is cheaper than a frequent false rejection. The design assumption is ownership, and that assumption is the thing an administrator has to actually implement.

What This Does Not Affect

Three clarifications, because "silent overwrite" makes people nervous about the wrong things.

Completed work is never moved. Operations with an actual start and an actual end stay exactly where they happened, no matter who runs the scheduler or when. The engine replans forward from where the job actually stands. That guarantee is independent of anything on this page.

Accepted schedule changes are recorded. A reschedule that you accept writes an entry to the schedule change history for the job, so "what moved and when" remains answerable. See the schedule change log.

Security events are recorded permanently. Sign-ins, failed attempts, lockouts, user and role changes, and permission denials all land in an append-only security audit trail inside the database. There is no browsing screen for it in the application, so it is queried by your administrator or support when a compliance question arrives, but it is written whether or not anyone looks.

What last-write-wins governs is narrower than it sounds: two people saving the same record in the same short window.

The Three Rules That Prevent It

Divide master data by owner. This is the whole answer, and everything else is a refinement. One person owns work centers and shifts. One owns products and routings. One owns customers. Everyone owns their own orders. Collisions need two people in the same row at the same time, and clear ownership makes that vanishingly rare. Write the division down in your plant conventions, because it is a convention rather than a setting.

Reopen before editing. A screen that has been open since this morning holds this morning's values. If a record has been sitting on someone's second monitor for four hours and they now change one field, they are about to write four-hour-old values over everything else. Closing and reopening the record before editing costs two seconds.

Save small, save promptly. A planner who edits eight fields across three records over twenty minutes has a twenty-minute window to lose in. A planner who saves after each record has a two-second one.

Where Else the Same Idea Shows Up

Two settings behave differently enough to be worth naming, because administrators often assume they follow the same rule.

Role permission edits apply to everyone holding the role, but they load when a user signs in. So a change made while a planner is working reaches them at their next sign-in, not immediately (a user signed in on the same machine picks it up straight away). If you edit a role and the person reports no change, have them sign out and back in before you investigate anything else. This is the most common false alarm in user and permission mistakes.

Site scheduling policy is read fresh on every scheduler run, with no restart. That makes it easy to change and easy to change under someone. Two administrators adjusting policy in the same afternoon is the same collision in a different costume, and the fix is the same: one owner, changes announced. See choosing a safe change window.

The Practical Summary

Last-write-wins is a small contract with a large implication: in a shared deployment, ownership is a design decision your plant makes, not one the software makes for you. Make it explicitly and this behavior never costs you a thing. For the full administrator reference, read the EDGEBIC admin guide; for the rollout that leads to a shared database in the first place, planning a multi-user rollout; and for the fundamentals underneath, what production scheduling is.