Eight Configuration Mistakes in EDGEBIC (and What They Look Like)

Scheduling software configuration mistakes almost never announce themselves with an error. A setting saves cleanly and nothing changes. Drags vanish on refresh. Job totals read double what the floor reports. In EDGEBIC by User Solutions each of these has a documented cause, and most of them come down to one of two things: policy applies at the next run rather than at save, or a display setting is being asked to do an engine's job.

The map of where settings live is in EDGEBIC configuration options explained. This post is the symptom list.

1. The Policy Change That "Did Nothing"

Symptom. You change a scheduling policy, save, look at the Gantt, and nothing is different.

Cause. Policy is read at the start of a scheduler run, not applied at save. Saving records the decision; running applies it.

Fix. Run the scheduler after saving, then compare. The sequence is always save, then run.

This single behavior is the most common configuration support call there is, and it has a good reason behind it: a policy that took effect mid-session would change the plan under a planner who was reading it.

2. New Orders Still Schedule Forward After Switching to Backward

Symptom. The site default is now Backward, and the plan still looks the same.

Cause. Direction is stamped on a job at creation. Existing orders keep the direction they were created with.

Fix. Change direction on the individual orders that matter, or recreate them. New jobs and quotes from today inherit the new default without any per-order action, so the fleet converges over a planning cycle or two.

That behavior is protective rather than awkward: a policy change should not silently re-time work that customers already have dates on. What the two directions actually do is covered in forward vs backward scheduling.

3. Gantt Drags That Disappear on Refresh

Symptom. A planner rearranges several operations, navigates away, and comes back to the original plan.

Cause. The default update mode batches edits. Drags and resizes accumulate as overridden changes and persist together when you click Save Changes.

Fix. Click Save Changes on the Gantt before navigating away.

Do not "fix" it by switching to instant persistence on a shared planning station. Batch save plus review-before-commit is the safety net that makes an accidental drag recoverable. Instant persistence belongs on single-purpose stations where every drag is deliberate.

4. Job Totals That Read Double or Triple

Symptom. A job's hour total is roughly a multiple of what the shop floor reports for the same work.

Cause. Synchronized parallel machines. Three mirrored drill heads on one operation genuinely consume 24 machine-hours between them, while the job took 8 hours of elapsed work. Roll-ups count all three by default.

Fix. Tick Primary hours only (exclude parallel) under Job-Level Hours in the Schedule settings. Totals then count the primary path everywhere hours roll up: routing header totals, Job View, and reports. It moves no operations.

Both numbers are legitimate answers to different questions. Pick the one your plant means when it says "hours". Background in EDGEBIC parallel work centers explained.

5. A Variance Flag on Nearly Every Bar

Symptom. The variance indicator lights up so often that people stop seeing it.

Cause. The variance threshold is set too low. It is the minimum plan-versus-actual difference, in minutes, before the flag appears, and it defaults to 30.

Fix. Raise it to something you would actually act on, typically 30 to 60 minutes. A threshold of zero turns the overlay into noise, which is worse than not having it.

6. Expecting Allow Conflicts to Prevent Overbooking

Symptom. Someone unticks Allow Conflicts, drags a job onto an already-full day, and no warning appears.

Cause. The Gantt uses an override-and-warn model. Feasibility of a manual drag is the planner's call, and the next scheduler run resolves what the drag created. That option changes what the control permits visually; it does not add a capacity check.

Fix. If drags must be prevented, untick Allow Drag, or control the drag-reschedule right by role. If they should be allowed but supervised, leave the post-save sequencing warning on: it tells you which jobs may have fallen out of sequence.

The capacity math that does hold the line runs inside the scheduling run itself. See finite vs infinite capacity scheduling.

7. Reading the Shaded Work Hours as Capacity

Symptom. Operations appear outside the shaded work-hours band and someone reports that the engine ignored the calendar.

Cause. That shading is cosmetic, a display default for the day and week views. Real capacity always comes from your shifts, plus any per-day or per-month capacity overrides on the work center.

Fix. Check the shift definition on that work center rather than the shading. On a second-shift work center, work outside the band is correct. See EDGEBIC shifts and calendars explained.

8. Changing Policy Mid-Shift Without Telling Anyone

Symptom. Supervisors report that "the plan has gone strange" the morning after a settings change.

Cause. Policy settings alter what the next run produces for everyone. Switching partial-confirm behavior from forward-shifting to trusting the operator's finish stamp, for instance, legitimately pulls downstream work earlier across every job with a short confirm on it.

Fix and prevention. Change policy at a quiet moment, tell the team what to expect, and run one schedule and read it yourself before the floor does. A surprise in the plan costs more trust than any single setting is worth. The wider rollout discipline is covered in change management for scheduling.

Four Smaller Ones

Short operations impossible to click. Raise the visual minimum duration so bars shorter than that many hours are drawn wider. It is display only; the schedule data is untouched.

Display settings lost after experimenting. Reset to Defaults restores factory settings, and Import restores a previously exported configuration. Which is the argument for exporting your tuned configuration once, before anyone experiments.

Looking for the optimizer's goal and time budget in Settings. They are not there, and that is deliberate: Settings stores only which optimizer engine runs. The goal preset and the time budget are chosen per run on the Optimizer tab, because they are decisions about one optimization rather than about the site. See EDGEBIC optimizer goals and presets explained.

Turning off sub-assembly inclusion without meaning to. With the setting on (the default), sub-assembly routings are exploded and scheduled with their parent job. Turn it off and only the top-level routing is planned for a multi-level product, which changes what gets planned rather than what gets displayed. If a multi-level product suddenly schedules in a fraction of the time it used to, check this setting before checking the routing.

Why These Repeat

Look down the list and two root causes cover almost all of it.

Timing. Policy applies at the next run. Direction is stamped at creation. Gantt edits persist on save. Three different timings, none of them "immediately when I click", and every one of them produces a symptom that reads as "the setting did not work".

Scope. Display configuration is per machine and per user; policy is site-wide; capacity and calendars are master data on the work center. A setting hunted for in the wrong scope is either not found or found and misread.

A configuration change that surprises someone is nearly always one of those two, which is why the triage below starts with both.

The Habit That Prevents Most of Them

One practice removes more of this list than any individual setting: write down what you changed, when, and why.

A scheduling system accumulates configuration decisions over years, and the ones that cause trouble are never the recent ones. They are the setting somebody flipped eighteen months ago for a reason nobody recorded, which now looks like a bug because the reason no longer applies. A four-column note (date, setting, old value, why) costs a minute per change and answers the question that otherwise costs an afternoon.

Pair it with the export habit on the display side. Tune the Configuration tab until the Gantt reads the way your plant thinks, click Export, and keep that file with the note. Between the two, a reinstall, a new planner's PC, and a "why is this set like that?" question all have the same short answer.

The Five-Question Triage

When a configuration complaint arrives, these five questions resolve most of them without opening a support case:

Where to Go Next

Read how to configure scheduling policy in EDGEBIC for the seven engine decisions in detail, and the settings that change how your schedule looks for the display-versus-engine boundary and the traps inside it. Broader diagnosis lives in the EDGEBIC troubleshooting guide, and the whole product in the EDGEBIC complete guide.

Bring the setting your team disagrees about to a demo of EDGEBIC, and we will show you which side of the line it sits on.