How to See Which Jobs a Run Will Touch Before You Commit in EDGEBIC

To see which jobs a run will touch before you commit in EDGEBIC, read the two scope signals: the rows you tick define what the run touches, and the Confirm Scheduling dialog reports the new-versus-existing split before you press yes. EDGEBIC by User Solutions never touches a job you did not select, and cancelling keeps nothing partial. The confirm dialog is your last cheap check on scope before anything writes.

This is the pre-commit check. For confirming what a run actually changed afterward, read how to check what a scheduling run changed; for the run itself, how to run the scheduler in EDGEBIC. It is one of the task guides in the EDGEBIC how-to hub.

Before You Start

The Two Signals That Tell You Scope

1. Your Selection

Scope comes entirely from the rows you tick. A ticked job is in the run; an unticked job keeps its plan and its reserved capacity and is not touched. This is the primary control, so the discipline is simple: tick exactly what you mean to move and nothing else.

2. The Confirm Scheduling Dialog

After you press Schedule + Re-Schedule, the Confirm Scheduling dialog appears before anything writes. It states the split, for example "You are about to schedule 5 job(s): 3 new job(s) and 2 existing job(s) that will be rescheduled." Read the number against your intent. If it does not match, cancel and fix your selection.

Step by Step

1. On the Drive Schedule tab, tick the jobs you intend to touch.
2. Press Schedule + Re-Schedule.
3. If nothing was ticked, the Schedule All Orders prompt appears. Answer No to keep your intended scope.
4. Read the Confirm Scheduling dialog and check the job count and the new-versus-existing split.
5. If the scope is right, answer Yes. If not, cancel, correct your ticks, and run again.

Even after you commit, the progress overlay carries a Cancel button, and cancelling keeps nothing partial, so an interrupted run leaves the previous plan standing.

If You Need to Preview the Actual Plan

The confirm dialog previews scope, not dates. To see the resulting plan before committing:

• Run a what-if scenario simulation, which uses the same engine and writes nothing.
• Use the optimizer, which proposes a plan and changes nothing until you press Accept.

Both let you inspect real dates without touching the live schedule.

Reading the New-Versus-Existing Split

The confirm dialog does not just count jobs, it splits them, and the split is informative. New jobs are first-time schedules with no existing plan. Existing jobs already carry a plan and will be rescheduled. That distinction tells you whether your selection is doing what you think.

If you meant to reschedule five jobs that are already on the plan and the dialog reports several new jobs among them, you have accidentally ticked unscheduled rows, perhaps because a filter was hiding the difference. If you meant to add only new work and the dialog reports existing jobs to be rescheduled, you have swept in jobs that already have plans and are about to move them. Either way, the split catches the mistake before a single row is written, which is far cheaper than untangling it afterward.

On a plant-wide pass the count is your one guard against an over-broad selection. Ten jobs when you expected three is the moment to cancel, not the moment to press yes and hope.

How to Check It Worked

1. Confirm the dialog's job count equals the number of rows you ticked.
2. After the run, open a job you did not select and confirm its dates did not move.
3. If the count surprised you, review whether a Schedule All Orders prompt was answered yes.
4. For a full after-the-fact check, run the reschedule history report on the touched jobs.

Common Mistakes and Gotchas

• Answering yes to Schedule All Orders. That prompt only appears when nothing is ticked, and yes pulls in every order. The confirm dialog's inflated count is the tell.
• Expecting a plan preview from the confirm dialog. It reports scope, not the resulting dates. Use a scenario or the optimizer for a real preview.
• Ignoring the split. New jobs get a first plan; existing jobs are rescheduled. If you expected zero new jobs and the dialog shows several, you may have ticked unscheduled rows by mistake.
• Committing on a large run without reading the count. On a plant-wide pass the number is your one chance to catch an over-broad selection cheaply.

The habit worth building is to treat the confirm dialog as a checkpoint, not a speed bump. On a small daily pass the count will usually match your ticks and you approve without a second thought. On a bigger pass, or when a filter is active and you cannot see every ticked row at once, the count is the only place the true scope is stated plainly before anything writes. Reading it costs a second and catching an over-broad selection there costs nothing, while catching it after the run means untangling bars that should never have moved.

To see the change record after a run, use how to run the reschedule history report, and to keep a run narrow, how to reschedule only the jobs that changed.

Bring your plan and we will walk the scope check against your data in one session. Contact US to book it, or read the EDGEBIC product overview first.