Auto Re-Sequencing: Closing the Gap After a Gantt Drag in EDGEBIC

Auto re-sequencing in EDGEBIC pushes the later operations on the same machine forward after you drag a bar, so the queue re-tightens instead of leaving a gap or an overlap, and every pushed operation is staged in the same pending set as your original move. EDGEBIC by User Solutions makes this optional, because sometimes you want the cascade and sometimes you want to move one bar by hand. This post explains what it does, how it stages, and when to switch it on or off.

The visual scheduling pillar guide covers dragging in general; here we focus on what happens to the bars behind the one you moved.

The Gap Problem a Drag Creates

Drag an operation earlier on a busy machine and you open a gap where it used to be. Drag it later and you may push it on top of the operation already sitting there. Either way, the machine's queue is no longer tight. Fixing that by hand means dragging each following operation, one at a time, until the line closes up again. On a packed work center that is tedious and error-prone.

Auto re-sequencing does it for you. When it is enabled, moving one operation cascades to the operations behind it on the same work center: each shifts to start immediately when the previous one ends, so the queue packs back down automatically. One drag re-tightens the whole line.

How the Cascade Stages

The cascade does not save on its own. It follows the same deferred-apply model as every other edit, which is what keeps it safe. When auto re-sequencing fires:

1. Your dragged bar turns to the Overridden state, pending.
2. Each later operation on that machine that the push moves also turns Overridden and joins the pending set.
3. The pending-changes count on the toolbar rises by the whole group, not just your one drag.
4. Save Changes writes the entire set at once, and Discard reverts all of it.

This is why a single drag can suddenly show several pending bars, and it is by design. The cascade is a proposal like any other, staged so you can review it before committing. If the new order is right, save it; if not, discard the whole thing and try again. For the full picture of how pending changes work, see staging changes with Save and Discard.

An optional refinement removes any residual gaps entirely, packing the following operations with no slack between them. Whether you want a tight pack or a simple forward push is a configuration choice.

Not the Same as the Downstream Flag

It is easy to confuse auto re-sequencing with the downstream flag, and they are genuinely different:

Auto re-sequencing keeps a machine's queue physically tight. The downstream flag is a "please review" signal that an earlier step in a job moved and a later step in that job may now be out of sequence; it writes nothing. Both can appear after one drag, and reading them together tells you a full story: the machine re-packed itself, and one job elsewhere needs a look. The downstream side is covered in how drag and drop shows the ripple.

Keeping One Operation Out of the Cascade

Sometimes you want the queue to re-tighten but one specific operation to stay put. Lock it first. Right-click the operation and choose Lock Single Operation Segment in Current Position, and the cascade flows around it instead of pushing it. This is the clean way to say "re-pack the machine, but not this step."

If a cascade has already pushed something past where you wanted it, remember nothing is committed while the bars are Overridden. Press Discard to revert the whole set, lock the operation you need fixed, and drag again. Because the pushes stage rather than save, an unwanted cascade is always reversible before it becomes real.

A Worked Cascade

A rush job needs to jump ahead on a machine that already has three jobs queued behind its current operation.

1. With auto re-sequencing enabled, you drag the rush job's operation earlier on the machine.
2. The three jobs behind it each shift forward to start when the previous one ends. The queue re-tightens automatically.
3. The pending count reads 4: your drag plus the three pushed operations, all Overridden.
4. You scan the new order. It looks right, so you press Save Changes and the whole set commits together.

One deliberate move, one review, one save, and a machine's entire queue re-sequenced cleanly.

When to Turn It Off

Auto re-sequencing is powerful when you want a machine to stay packed, but there are times you would rather move bars one at a time: delicate hand-tuning of a queue, a change where you want to see the gap before deciding, or a machine whose order you are deliberately spreading out. For those, turn the option off in the scheduler configuration and each drag moves only the bar you grabbed.

The general rule: enable it when tightening machine queues is your routine, and disable it when you want surgical, single-bar control. Either way, remember that saving a re-sequenced set records dates without re-running capacity, the same override-and-warn contract that governs every edit. When you want the engine to re-plan around the new order, press Re-Schedule, which touches only the jobs you changed. Deciding how tightly to pack a machine is exactly the kind of trade-off that job shop scheduling lives on, and EDGEBIC gives you both the automatic pack and the manual move.

Why It Is Optional

A scheduler that always re-sequenced would take control away from the planner, and one that never did would make every queue-tightening a chore. EDGEBIC makes it a switch, so the behavior matches how you actually work. When it is on, a single drag keeps a machine's line honest; when it is off, you move one bar at a time. And because the cascade stages like everything else, you always see the full proposal before it becomes the plan, and you can lock the one operation you need to protect.

See the full EDGEBIC platform, or bring a packed machine's queue to a demo, move one rush job to the front, and watch the line re-sequence itself with US.