What Is a Pending Schedule Change in Scheduling?

A pending schedule change is an edit made on a scheduling board that has been staged in memory but not yet written, existing only on the screen of the planner who made it until they explicitly save. Dragging or resizing an operation creates one: the bar takes a distinct color, a pending count on the toolbar increments, and nothing else in the plant knows anything has happened. In EDGEBIC by User Solutions the staged set is committed with Save Changes or thrown away with Discard, and the same staging applies whether you moved one operation or twenty.

How it works

The board separates the gesture from the write. A drag never touches the database. What it does is three things at once: it moves the bar on screen, it flips that operation into the override state so the change is visible as unsaved, and it adds the operation to a pending set that the toolbar counts.

The set accumulates. Every further drag joins the same set. Because the moves stage together, a planner can compose a sequence that only makes sense as a whole. Pulling one operation forward is often only correct if a second one moves back, and staging is what lets those two edits be considered together and committed together rather than existing separately for however long it takes to make the second one.

The set is local. Nobody else can see it. This is what makes an exploratory drag free: you can pull an operation across three days to see how it looks, decide against it, and discard, and no colleague, no report, and no scheduling run will ever have known.

The set commits as one act. Save writes every staged operation. What each write actually records depends on a separate mode setting rather than on the drag itself, so the same staged set can be committed as recorded history or as future intent. After the write, each bar takes a state describing what was recorded.

The set discards as one act too. There is no per-operation undo inside the pending set. Discard snaps every staged bar back to where the engine had it. That symmetry is deliberate: a set that could be partially unwound would need its own history, and the audit trail exists precisely so that committed changes have a proper record while uncommitted ones need none.

One consequence follows from all of this and is worth stating plainly. A pending change is the only thing on a scheduling board whose information exists nowhere but the display. Everything else can be recovered by reloading. Pending work cannot.

A concrete example

A planner has three moves in mind on Monday morning. The mill was down over the weekend, so its operation needs to slide to Tuesday. That pushes paint, which needs to slide to Wednesday. And a small job currently sitting on Tuesday afternoon can be pulled forward into the gap the mill just left.

The planner drags the mill bar. It turns the override color; the toolbar reads one pending. They drag paint. Two pending. They drag the small job into Monday's freed slot. Three pending.

At this point the board shows a plan that is coherent and complete, and that exists on exactly one screen in the building. A colleague opening the same board sees Monday's mill still there and the small job still on Tuesday. That is correct: nothing has been decided yet.

The planner looks at the composed result, decides it works, and presses save. All three operations are written in one act. The mill and paint bars take the applied state; the small job takes it too. The audit trail now carries three entries with old and new dates.

Had the planner instead spotted a problem, one press of discard would have returned all three bars to their engine positions with nothing written and nothing to explain. The important property is that neither the intermediate two-move state nor the abandoned three-move state ever existed as far as the rest of the plant is concerned. Composing edits in the open is exactly what staging buys.

How EDGEBIC uses it

Staging is what makes the board's override-and-warn philosophy workable. EDGEBIC lets a planner place work almost anywhere and warns rather than blocks, on the principle that the person at the screen often knows something the data does not. Without staging, that permissiveness would mean every exploratory drag immediately became a fact. With staging, exploration is free and only the conclusion is recorded. The workflow itself is covered in how to batch your Gantt edits before saving in EDGEBIC.

Two things determine what a save actually means. The first is the mode selector, described in what is a drag write mode in a production gantt, which decides whether the commit records history, an in-progress start, or a future pin. The second is the resulting bar color, which is the provenance record laid out in what is an operation state in a production gantt.

After a save the plan reflects what you decided but not what the engine would do about it, because a saved drag does not re-run capacity math. Closing that loop is a separate step described in what is a targeted reschedule, which re-plans only the jobs you touched. For the wider mechanics of moving work on the board see drag and drop rescheduling in EDGEBIC.

The takeaway

A pending schedule change is a decision you have not made yet, held somewhere it can be examined before it becomes real. That framing explains all of its properties at once: it is invisible to others because it is not a decision, it discards wholesale because a set of moves is one decision, and it is lost on exit because an unmade decision has nothing to preserve. The one habit that matters is checking the pending count before leaving a board, since it is the only figure on screen whose information lives nowhere else. For the wider vocabulary see the manufacturing glossary, and for the product itself see EDGEBIC.