What to Decide Before Several Workstations Share One EDGEBIC Database

EDGEBIC handles the mechanics of several planners against one database. The decisions it cannot make for you are the ones that determine whether the shared plan is calm or chaotic. In EDGEBIC by User Solutions the technical safeguards are automatic once you choose a shared database, so the work left to do is entirely about agreement.

This post is the decision list. For the rollout sequence, which phase follows which, read planning a multi-user rollout. For what technically changes underneath, read what changes when EDGEBIC moves to a shared database.

What the Software Already Handles

Worth stating first so the list below stays short.

Two planners editing the same record cannot silently overwrite each other, because the second save is refused with a message rather than applied. Two people cannot run the scheduler at the same time, because a plant-wide rule admits exactly one run and tells the second person to wait. A change made on one workstation reaches the others within a few seconds without anybody pressing anything. And a manual refresh exists as a deliberate backup for the cases the automatic path does not reach.

None of that needs configuring. Choosing SQL Server as your data source turns all of it on.

The Eight Decisions

1. Who Runs the Scheduler, and When

The software guarantees that two runs cannot produce one incoherent plan. It cannot stop a run from being a surprise.

A run rewrites the forward plan. Someone mid-way through staged Gantt edits, or reading a job list to promise a delivery date, is suddenly working from something that moved. That is what a reschedule is for, and it is disruptive when it arrives unannounced.

So name one owner and a cadence: first thing each morning, or after each batch of new orders, plus a word before an unscheduled run. Why only one run happens at a time covers the mechanism; the cadence is yours to choose. How to reschedule safely covers the run itself.

2. Who Owns Each Area of Master Data

The refused save stops silent loss. It does not stop wasted work: the second person still has to reload, look at what changed, re-apply their edit, and save again.

Ownership by area removes the collision rather than handling it. One person for work centers and calendars, one for routings, one for the order book, one for products. Two people rarely have a reason to edit the same product on the same afternoon once responsibilities are named.

This matters more than it sounds because a few edit screens do not yet carry the version check through, so their saves still behave as last-write-wins. Routings in particular are worth putting under a single owner. Why EDGEBIC refuses a stale save is honest about which screens are covered.

3. Where Integrations Run

By default, any open EDGEBIC workstation can dispatch scheduled and file-watched integrations. On one PC that is right. On a shared database it means an overnight ERP pull only happens if somebody left their machine on, and which workstation runs a given sync is arbitrary.

Decide before go-live whether an always-on service will host them on the server. If yes, install it, configure its data source under the account it runs as, and turn hosting off on each workstation. If no, be explicit about the gap rather than discovering it in November. Why your ERP sync belongs on a server covers the decision and its consequences.

Decide too who is allowed to configure integrations, which is a permission rather than a convention.

4. Which Fields Your ERP Is Master Of

This is the collision the software deliberately will not referee.

Imports run as last-write-wins. Refusing four thousand rows because one planner had one product form open would be a far worse outcome than the race it prevents, so the sync applies. If a planner edited a lead time in EDGEBIC this morning and the sync brings the ERP's value tonight, the ERP wins, quietly.

So decide per field. Where the ERP is master, planners raise the change upstream and stop editing it in EDGEBIC. Where EDGEBIC is master, take the field out of the import mapping so the sync never touches it. A field with two masters will keep changing on its own and nobody will be able to say why.

5. Where Site Scheduling Policy Is Decided

The engine settings, scheduling direction, how a backward job that does not fit is handled, and their siblings, are one shared configuration for the whole site rather than a personal preference.

That makes them a decision, made once, communicated. Changing one quietly under a team that is relying on it produces exactly the kind of unexplainable plan change that erodes trust. Name who may change them and what the notification looks like.

6. Who Reviews Run History, and How Often

An unattended sync is only as good as somebody's ability to confirm it ran. Run history is that confirmation, and it needs a reader.

A weekly five-minute look answers the two questions that matter: are the hosts I expect alive and recently seen, and does each integration show recent runs with sensible counts. The failure this catches is the quiet one: a sync that stopped attempting entirely, which produces no failed run to trip over. How to tell whether anything is actually hosting your syncs covers what to look at.

7. The Refresh Habit

Teach this on day one rather than letting people discover it in month three.

A screen loads its data when you open it, and although changes made elsewhere reach open screens automatically within a few seconds, a few surfaces sit outside that path. So: before you make a promise from a number on a screen that has been open all morning, press refresh.

Also teach that reopening a tab is not the same as refreshing, because shared lists are held in memory for the session and a reopened screen can serve the same stale value again. What the refresh button actually does covers that difference.

8. Layouts Stay Personal

The one thing not to decide. Column widths, ordering, grouping, filters and Gantt display settings are saved per user automatically.

A planner who wants twelve columns on the job list and a supervisor who wants four are not in conflict and do not need a standard imposed. Two people can configure the Gantt entirely differently and still be looking at the same plan, because display settings change what you see and never what the engine computed. Say so once and the question stops being asked.

The Order to Settle Them

If you can only agree three things before the switch, agree the scheduling run owner, master data ownership, and where integrations run. Those three change how people's days feel and are much harder to introduce after everyone has formed habits.

The rest, roles and accounts, backups, review cadence, the refresh habit, can be settled in the weeks after go-live without anybody having to unlearn anything.

The full administrator reference is the EDGEBIC admin guide, and keeping the database healthy over time covers what changes about maintenance once a server is involved.