How Drag and Drop Shows the Downstream Ripple

When you drag one operation in EDGEBIC, the later steps that might now be out of order turn amber, and that is the downstream ripple. Moving an operation does not just move that bar. It changes when the operation finishes, and every later step in the same job that depends on that finish is now in question. EDGEBIC marks those steps with the Downstream Changed color, a review flag that shows you the reach of your change before you commit to it. EDGEBIC by User Solutions makes the ripple visible so a manual move never quietly leaves a job out of sequence.

This post explains what the ripple is, why it is a signal rather than a change, and how to resolve it. It builds on drag and drop rescheduling in EDGEBIC and sits under the visual scheduling guide.

A Move Is Never Just One Bar

Operations in a job run in order. Step two waits for step one; step three waits for step two. When you drag step one to a later slot, you have changed the foundation the whole chain stands on, because everything downstream was planned to start after step one finished at its old time.

EDGEBIC recognizes this. After you move an operation and it is saved, the system looks at the same job for every operation that now starts at or after your moved bar's new end time, and marks each one Downstream Changed. On the Gantt those bars turn amber. The color is not saying "these are broken." It is saying "these may now be out of sequence, please review." The ripple is the visible answer to the question every manual move raises: what else did I just affect.

The Flag Is a Signal, Not a Change

It is essential to understand what the amber does and does not do, because misreading it leads to bad habits.

The Downstream Changed color writes nothing to the database. It does not move the flagged operations, does not change their dates, and does not block you from editing them. It is a pure visual signal layered on top of operations that are otherwise untouched. The engine has not re-planned anything; it has simply pointed at the steps your move put in doubt.

This restraint is deliberate. EDGEBIC follows an override-and-warn model: you are the planner, and the system trusts your judgment rather than auto-correcting behind your back. When you move an operation, EDGEBIC will not silently reshuffle the rest of the job. It flags the consequences and leaves the decision to you. That is the same philosophy behind the pros and cons of drag and drop scheduling: manual control is powerful, but only if the tool shows you the impact of using it.

Reading the Reach of a Move

The number of bars that flag tells you something worth knowing. Move an operation that few steps depend on and a couple of bars go amber. Move one that many steps depend on and the amber spreads widely.

A wide ripple means the operation sits early in a chain that a lot of work depends on. If moving one bar lights up eight downstream steps, that operation is load-bearing, and often it belongs to a constraint machine, because a constraint is precisely the operation the rest of the plant waits on. Watching the ripple spread is a live measure of how central a step is, and it is the same signal used when spotting a bottleneck on the Gantt. A change with a small ripple is contained; a change with a large ripple deserves a second look before you save it.

Two Ways to Clear It

The amber is a to-do list, and there are two ways to work through it.

Let the engine re-plan. After saving your move, press Re-Schedule. EDGEBIC remembers the jobs you touched and runs the engine on just those jobs, re-timing their remaining steps around your change while leaving the rest of the plant alone. When the Gantt reloads, the flagged steps sit in a valid sequence again and the amber is gone. This is the usual choice, because the engine re-plans a whole job's downstream correctly in one pass.

Place them by hand. If you want precise control, you can drag the flagged operations yourself to the slots you want. This makes sense when you know something the engine does not, such as a customer preference or a tooling constraint that is not modeled. You are trading the engine's speed for your own judgment on those specific steps.

Either way, the flags are meant to be resolved, not left standing. A schedule full of stale amber is a schedule where nobody can tell a reviewed plan from an unreviewed one.

A Related Behavior: Auto Re-Sequencing

The downstream ripple flags later steps in the same job. A separate, optional behavior handles later operations on the same machine, and it is worth distinguishing so you are not surprised by it. With auto re-sequencing turned on, dragging one operation on a resource pushes the operations behind it on that same machine forward to close the gap or resolve the overlap you created. Those pushed operations are not just flagged; they are actually moved, and each becomes part of the pending set, staged to save alongside your original drag.

The distinction matters. The amber downstream flag is a review signal that changes nothing until you act. Auto re-sequencing genuinely re-times other bars in memory, so a single drag on a busy machine can turn many bars into pending changes at once. That is correct behavior when you want the machine's queue to tidy itself around your move, but it means you should review the whole pending set before saving, because you may be committing more than the one bar you grabbed. If you prefer to move only what you touch, leave auto re-sequencing off and let the downstream flags guide a manual or engine-driven cleanup instead.

A Worked Example: The Two-Day Mill Slip

JOB-2026-0101 runs saw, then mill on CNC-Mill-1, then paint on Paint-Booth-1, planned back to back. The mill was down Monday, so the planner needs to push the mill operation two days later.

The planner drags the mill bar from its Monday slot to Wednesday. It goes orange, Overridden, staged but unsaved. The planner presses Save Changes. The mill bar turns green, Applied, at its Wednesday position. Immediately the paint bar turns amber, Downstream Changed, because paint was planned for Tuesday and now starts before the mill even finishes: it is out of sequence.

The amber is the whole point. Without it, the planner might save the mill slip and walk away, leaving paint scheduled for a day when the parts will not exist yet. Instead the flag makes the consequence unmissable. The planner presses Re-Schedule for the job. The engine keeps the mill's new Wednesday timing, re-plans paint to start after the mill finishes, say Thursday morning, and on reload the paint bar is a clean planned color again with no amber. One move, one visible consequence, one targeted re-plan, and the job is coherent.

Had the mill fed three later steps instead of one, all three would have flagged, and the same Re-Schedule would have re-timed all three at once. The ripple scales with the dependency; the resolution does not get harder.

The Ripple Is Honesty

A scheduling tool that let you move one bar and said nothing about the rest would be lying by omission. The whole risk of manual rescheduling is the change you did not think through, the downstream step you forgot depended on the one you moved. User Solutions has built scheduling tools for manufacturers since 1991, for shops and for names like GE and BAE Systems, and the downstream ripple is one of the small honesties that make manual control safe: you see what your move touched, every time, before you commit to living with it.

Move the bar, read the amber, and reschedule the job. Bring a real schedule to a demo and drag a load-bearing operation to watch the ripple spread. Give US a chance to show you the reach of a single move.