Eight Routing Snapshot Mistakes That Surprise Planners

Routing snapshot mistakes almost always come from the same root: assuming the copy behaves like the master routing, or assuming it can be undone. It does not, and it cannot. Below are eight mistakes that come up repeatedly in real EDGEBIC by User Solutions deployments, with the symptom each produces and the correction.

If the mechanism is unfamiliar, production routing snapshots covers what is frozen and why, and working with frozen routings is the procedure these mistakes shortcut.

1. Expecting a Master Edit to Reach Open Jobs

Symptom. Engineering releases a revision, you reschedule, and forty open jobs re-plan on the old work centers and old hours. Somebody concludes the revision did not save.

Cause. Every scheduled job plans against its own frozen copy by default. The master routing is edited and every new order picks it up immediately, but jobs already scheduled keep the version their paperwork describes.

Fix. Understand it as protection and act per job. The operator with a fixture bolted to the machine named on the old routing is the reason the default exists. Adoption is a decision, and the controls are on the Scheduled Job BOR tab.

This is the number one surprise and it is not a defect. It is worth explaining to a new planner on day one, because discovering it during a revision rollout produces the second mistake on this list.

2. Bulk Resetting From the Master

Symptom. Eleven jobs refreshed in one sitting, four of them lose per-job customizations, and there is no way back.

Cause. Reset from the master discards the job's copy entirely and replaces it with a fresh snapshot. Anything the copy held that the master does not, such as a one-off substitution, an added inspection step, or a corrected time for this quantity, goes with it. There is no prompt and no version history behind the record.

Fix. Use the follow-master flag instead for routine adoption. It achieves the same result on the next run without destroying the copy first, which means the run itself can be reviewed before anything is lost. Reserve the reset for a copy that has genuinely drifted somewhere unhelpful, and treat it as a two-person operation.

3. Skipping the Comparison

Symptom. A refresh produces changes nobody expected: a step gone, a work center moved, a queue time altered. Someone spends an afternoon working out which of those were intended.

Cause. The comparison against the current master reports field-level differences per step, and it takes seconds. It is easy to skip when you already believe you know what changed.

Fix. Run it before every refresh. Read the output with three questions: did a work center change, did any timing change materially, did steps appear or disappear. Most refresh decisions become obvious once the differences are on screen, and most bad ones happen because nobody looked.

4. Refreshing the Step That Is Currently Running

Symptom. An operation in progress re-plans against different timings, or a supervisor discovers the routing now names a different machine than the one with the fixture on it.

Cause. A refresh applies to the job's remaining work. Completed steps are safe because completed work never moves, and a started operation keeps its work center. But the timings and downstream sequence around a running step can still shift under it.

Fix. Decide by status. Refresh jobs with no actuals freely. For running jobs, refresh when the change affects only downstream steps, and wait until the current operation finishes when it does not. The middle of a setup is the worst possible moment to change what the setup is for.

5. Assuming a Version History Exists

Symptom. "Just roll it back" is proposed in a meeting and nobody can.

Cause. Each write to a job's copy overwrites the previous state. The copy carries a version number, a snapshot date, and a reschedule counter, so you can tell when it changed, but the prior content is not retained.

Fix. Capture before you change. The comparison report run immediately before a refresh is the practical record. For jobs where the routing is contractually significant, note or export the copy as part of your release process. The general discipline is covered in change control for scheduling.

6. Not Verifying a Designer-Added Step

Symptom. A step added on the canvas simply is not in the schedule. Not misplaced, absent. Nothing errors.

Cause. A job's copy is self-contained with no round trip through the master routing tables, so any field the save path leaves at its default stays at that default permanently. The documented instance is the end product association: the engine filters a job's steps by end product, and a step without one is dropped silently. Current versions stamp the field on save and repair existing copies on load.

Fix. After adding a step in the designer, reschedule and confirm it appears. Five seconds against a class of failure that produces no message. The same habit catches sequencing problems, where a step exists but was never wired into the flow: steps scheduled out of sequence covers those symptoms, and the graphical routing designer tour covers the canvas itself.

7. Missing the Silent Fallback

Symptom. A job schedules normally against timings nobody recognizes, and the copy on screen does not match the plan.

Cause. If a job's copy is empty or unusable, the engine falls back to the live master routing rather than failing the run, and records the deviation. That keeps the plant scheduling, which is the right default, but the job is now planning against a routing it was never committed to and the only signal is in the log.

Fix. Watch for integrity findings when copies load. The checks flag empty step lists, invalid product references, negative hours, and steps carrying neither a work center nor a product. An empty step list is the one that triggers the fallback. Any job showing it should be refreshed deliberately from the master so its copy is coherent again rather than absent.

8. Refreshing Without Re-Issuing Paperwork

Symptom. The schedule is right and the floor runs the old version anyway, because the traveler in the operator's hand still names the old machine.

Cause. A refresh updates the plan in seconds. It does not update paper, and it does not move a fixture.

Fix. Treat the refresh as half the job. A terminal will raise a banner when the live routing differs from the job's copy on work center, setup time, cycle time, or queue time, which is a useful backstop before an operator starts. But it is a notification, not a work instruction. Reprint the traveler and tell the supervisor who staged the setup.

A Ninth: Misreading What Hybrid Protects

Worth adding because it is a reasonable assumption that runs the wrong way.

Hybrid mode does not prevent rerouting. Work center assignments always come from the master when they differ, because a rerouting is an engineering decision. What hybrid protects is timing: run times and setup times are adopted only when the difference clears a materiality threshold, so validated improvements flow through and noise-level edits do not disturb a live job.

If your goal is to stop a step being rerouted mid-order, the tool is the job's own copy, not hybrid mode. The thresholds and worked numbers are in why frozen routings protect in-flight jobs.

A Timing Nuance That Looks Like a Mistake

Worth knowing because it produces an apparent inconsistency that is actually correct.

A brand new order has no copy, so its very first scheduling run reads the master routing. The freeze applies from that first schedule onward, not from order entry. So an engineering change made on Tuesday reaches every order first scheduled on Wednesday, automatically, with nobody doing anything.

The practical consequence is that two orders for the same product entered the same week can plan differently, purely because one was scheduled before the revision and one after. Neither is wrong. Each is a faithful record of what it was committed to.

The habit that avoids the confusion: when a revision lands, note the date. Any open order first scheduled before that date holds the old version and needs a decision. Anything scheduled after it already has the new one. That single question sorts the list faster than opening jobs one at a time.

The Pattern

Every mistake on this list is a mismatch between how the copy behaves and how people expect a routing to behave. A master routing is live, shared, and editable. A job's copy is frozen, private, and one-way.

Two habits cover most of it. Compare before you refresh, and verify after you change. Neither takes more than a minute, and between them they catch six of the nine.

Where to Go Next

Production routing snapshots is the concept. Working with frozen routings is the procedure. Why frozen routings protect in-flight jobs is the mechanism.

For the editing narrative on a single live order, see editing a live job's routing, and for symptoms that survive this list, the EDGEBIC troubleshooting guide. The platform overview is the complete guide to EDGEBIC. Bring a revision that went sideways to a demo of EDGEBIC and we will trace it.