My High-Priority Job Scheduled Behind a Lower One: Why, and the Fix

Priority in EDGEBIC sets the order in which jobs claim capacity during a run, not a guarantee that a high-priority job finishes first, so a top-priority job can still land behind a lower one when the two never compete for the same resource, when its release date is later, or when netting sequences a supplier ahead of it. EDGEBIC by User Solutions uses priority as the primary dispatch sort key, with start time and due date as tie-breakers, and dispatch order is about who grabs a contested slot first.

This post belongs to the EDGEBIC troubleshooting guide and extends job priority and sequencing strategy and the general forward versus backward scheduling.

What You Are Seeing

You set a job to your highest priority, expecting it to run first and finish first. When the schedule came back, a lower-priority job landed ahead of it: earlier start, earlier finish, better slot. The priority field is set correctly, the run completed, and yet the important job sits behind the routine one. It looks as if priority did nothing.

Why It Happens

Priority orders contention. It decides who wins a slot when two jobs want the same resource at the same time. It is not a calendar override, and three situations make that difference visible.

• The jobs never compete. Priority is the primary sort key, but it only arbitrates between jobs contending for the same work center. If the high-priority job runs through different work centers than the low-priority one, they never wait on each other, so priority never chooses between them. Each schedules from its own release date, and the earlier-releasing job finishes first.
• The release date is later. Dispatch order puts the high-priority job first in line, but the scheduler cannot start a job before its release or earliest-start date. A high-priority job released next week still schedules after a routine job released today, because the routine one is eligible sooner.
• Netting sequences suppliers first. When forward netting is active, a leading sort key places producing sub-assemblies ahead of the jobs that consume them, regardless of priority. A part that feeds your top-priority assembly is dispatched before the assembly, because the assembly cannot begin until its input exists. That is correct, not inverted.

Underneath, the sort is priority first, then start time, then due date. Priority genuinely wins among jobs that contend, which is exactly why the cases where it seems inert are the cases where no contention exists.

How to Fix It

Match the tool to what you actually need: an earlier finish, an earlier start, or a hard commitment.

1. Confirm the two jobs actually share a resource. If they run through different work centers, priority will never reorder them. This is the most common cause and it is working as designed.
2. Check the release date on the high-priority job. A later release keeps it out of the early slots. Pull the release date forward if the material and demand allow it.
3. Use a target date for a hard finish. Priority orders dispatch; a target start or target end date makes the scheduler build the job around a fixed date. That is how you pin a finish rather than merely a dispatch position (how to anchor a job to a target start date).
4. Consider the optimizer for tardiness. When the goal is fewest late jobs across the whole plan, a tardiness-weighted optimizer objective sequences for lateness directly, which priority alone does not do.

How to Prevent It

• Reserve priority for real contention. Priority earns its keep when many jobs fight for the same constrained work center. On resources with slack, it changes little, and that is expected.
• Keep release dates honest. A job released too late cannot be pulled early by priority. Align the release date with when the job truly can start.
• Anchor the jobs that carry a hard commitment. For dates you cannot miss, a target date is the right instrument, not a priority bump. See production bottleneck identification for protecting the constraint those jobs run through.
• Understand netting before you fight it. A supplier job ahead of its consumer is a dependency being honored, not a priority failure. Priority orders within a group, not across a genuine supply link.

If instead your job scheduled far later than any priority question would explain, that is a different symptom covered in a job was scheduled far in the future.