Staging Schedule Changes: Save and Discard on the EDGEBIC Gantt

Staging schedule changes before saving is the safety rail that makes the EDGEBIC Gantt safe to touch: every drag is held in memory as a pending change, nothing reaches the database until you press Save Changes, and one Discard click reverts the whole set. EDGEBIC by User Solutions calls this the deferred-apply model, and it is the reason a planner can rearrange a busy schedule with confidence instead of dreading a mis-drop. This post explains exactly what happens between the moment you grab a bar and the moment the change becomes real.

If you are new to reading the chart itself, start with the visual scheduling pillar guide; here we focus on the commit model that sits behind every edit.

Nothing Is Saved Until You Say So

Grab a bar and drop it in a new slot. The bar changes color to the Overridden state and the pending-changes count on the toolbar goes up by one. That is the whole visible effect. No schedule row has changed in the database, no report has moved, no other planner sees anything different. The move exists only on your screen.

This is deliberate. Interactive scheduling tools that write every drag straight through punish exploration: one clumsy drop becomes a committed fact you have to hunt down and reverse. EDGEBIC instead treats your drags as a proposal. You can move one operation or twenty, look at the resulting picture, and only then decide whether it becomes the plan.

Two buttons close the loop:

Because the whole set commits or reverts together, you never end up with half a plan. Either the batch you built is real, or it never happened.

The Overridden State: Your Unsaved Work, in Color

Bar color on the Gantt is a state language, and one state means "you, unsaved." A bar in the Overridden state has been dragged or resized but not yet persisted. It sits at its new position on your screen while the engine's original dates are still safely stored underneath.

The moment you Save, each Overridden bar moves to a committed state that records what you actually did:

If you Discard instead, the Overridden bar simply returns to whatever state it held before, most often the neutral Default state that means "the engine scheduled it, nobody has touched it." For the full color vocabulary, see colors and labels on the EDGEBIC Gantt.

Staging Several Moves as One Review

The real value of staging shows up when a disruption touches more than one operation. Suppose a mill goes down for the morning. You want to slide its job later, and while you are at it, pull a second job forward onto a machine that just freed up.

1. Set the drag mode, then drag the mill operation to its new afternoon slot. Pending count: 1.
2. Drag the second job's operation onto the free machine. Pending count: 2.
3. Look at the whole picture. Do the two moves conflict? Did the afternoon slot push anything past a shift boundary?
4. Satisfied, press Save Changes. Both commit together. Or press Discard and both vanish.

You reviewed a coherent set before committing anything, which is exactly how a planner thinks: not "is this one drag right" but "is this arrangement right." This is the same discipline good schedulers apply to any job shop scheduling decision, made visual.

The One-Undo Rule

There is a limit worth memorizing: Discard reverts the entire pending set, not one bar. EDGEBIC has no per-bar undo inside the staging area. If you have three staged drags and decide two are good but one is wrong, Discard is the wrong tool, because it would throw away all three.

The correct move is to Save all three, then reach for the right-click menu on the single bar you regret. Clear Operation Actual Start and End Date/Times returns that one operation to its engine-planned position and clears the actual dates you wrote, leaving the other two exactly where you put them. In practice this means you should build a pending set you are willing to commit or abandon as a whole. When in doubt, save in smaller batches.

Saving Records Dates. It Does Not Re-Plan Capacity.

Here is the point planners most often miss, and it is central to how EDGEBIC works. When you Save a drag, EDGEBIC writes the dates you chose. It does not re-run the scheduling engine, and it does not re-check whether the machine has room. This is the platform's deliberate override-and-warn contract: you can drop a bar onto an already-busy afternoon, EDGEBIC will warn you about a questionable move but will not block you, and the save records your decision as fact.

That trust is the point. You are the planner, and sometimes you know something the calendar does not: an operator agreed to stay late, a second setup is genuinely possible, the "overload" is really two short jobs that fit. EDGEBIC stages your judgment and lets you commit it.

When you do want the engine to re-plan the rest of the job around your move, that is a separate, explicit step: the Re-Schedule button, which re-plans only the jobs you touched and leaves the rest of the plant alone. Saving and rescheduling are two different actions with two different meanings, covered in drag-and-drop rescheduling.

A Practical Habit

Treat the Gantt as a place you can think out loud:

• Drag freely. Nothing is committed while bars are Overridden.
• Watch the pending count so you always know how much unsaved work you are carrying.
• Save when the arrangement is right, Discard when the experiment is over.
• Keep batches small enough that committing the whole set is a comfortable decision.
• Reach for the right-click clear-actuals items only after a save, when you need to reverse one specific operation.

Staging is not a limitation to work around; it is the feature that lets a planner explore a real schedule without fear. Every drag is a proposal, every Save is a decision, and every Discard is a clean slate.

See the full EDGEBIC platform, or bring last week's disrupted schedule to a demo and stage a recovery on it with US, committing nothing until the picture is right.