Released vs Unreleased Jobs in Scheduling

A released job is one authorized to start and ready for the floor, with material on hand and approval granted, while an unreleased job is planned in the system but deliberately held back. Release is the gate between planning a job and turning it loose on the shop floor, and it is one of the most underused levers in scheduling. Releasing everything the moment it is approved floods the floor with work-in-process; releasing at the pace the shop can actually run keeps queues short and lead times predictable. EDGEBIC by User Solutions lets you schedule a job to see where it lands while controlling when it actually enters the floor through start dates and priority.

Scheduling a job is not the same as releasing it

These are two separate decisions that get conflated all the time.

Scheduling answers where a job would run: which machines, in what sequence, finishing when. You can schedule a job to see its impact without committing anything, the same way a quote simulation shows a completion date without disturbing the live plan.

Releasing answers whether the job goes to the floor now. A released job has cleared its prerequisites: material has arrived, the order is approved, and the shop is ready to take it. An unreleased job sits in the plan but is held, because one of those conditions is missing or because the floor already has enough in front of it.

Keeping the two distinct is what lets you plan aggressively and release conservatively. You can see the whole future plan while turning loose only the work the shop is ready to run.

Why holding work back is a feature, not a delay

The instinct to release every approved job immediately feels like progress, but it usually backfires. The reason is that lead time is mostly queue time, not run time. A part spends far more of its life waiting in front of machines than being worked on. The more jobs you release, the longer every queue grows, and the longer every job waits.

Hold work back until the shop is ready and the opposite happens. Queues stay short, jobs flow through quickly, and lead times shrink without adding a single hour of capacity. You also gain clarity: when only the work the floor can run is on the floor, operators can see what is actually next, instead of hunting through a pile of work-in-process for the real priority. This is the heart of pull scheduling: release at the pace of consumption, not the pace of arrival.

A worked example

Your bottleneck is a heat-treat oven that runs 60 parts per day. On Monday morning, 20 orders totaling 300 parts are approved.

Release everything (push): all 300 parts of raw material go to the floor Monday. By Tuesday, five days of work-in-process is stacked in front of the oven. Every job now waits four to five days in the oven queue before its turn. A product whose actual routing takes 4 days now takes 12, entirely because of queue. Cash is tied up in 300 half-finished parts, and no one can tell which order is really next.

Release at the drum's pace (controlled): the oven has three slots Tuesday, so about 60 parts. You release only enough raw material Monday to feed Tuesday's slots, then another day's worth Tuesday for Wednesday, and so on. Work-in-process in front of the oven stabilizes at roughly one day, about 60 parts, instead of five days. The same 300 parts still get made, but lead time collapses from 12 days back toward the routing's real 4, and the queue never hides the priority.

Same orders, same oven, same total output. The only difference is when you turned the work loose.

How to control release in EDGEBIC today

The engine schedules the orders you give it, in a deterministic sequence by priority, then start date, then due date. That sort, described in how a scheduler decides when to start a job, is also your release toolkit:

• Start date gates when an operation is eligible to begin. Set start dates so work arrives at the constraint just ahead of when the constraint has a slot, rather than dumping everything at day one.
• Priority decides which eligible jobs claim capacity first when a slot opens, so you control the order of release under contention.
• Order selection decides what enters the plan at all. You can hold an order out until its material and approval are confirmed, then bring it in.

Because completed work is never moved by a reschedule, released and in-progress jobs stay put while you manage the release of what is still ahead.

Automated pull-style work release, where the system paces material release to the bottleneck's rate on its own, is a capability on the product roadmap rather than a button today. The honest workaround is the manual discipline above: use start dates as your release valve, priority as your tie-breaker, and a short controlled queue at the constraint as your target. It takes planner attention, but it delivers the same lead-time benefit the automated version would, using the controls that exist now.

The takeaway

Release is a decision you make on purpose, not a default that fires the moment an order is approved. Treat scheduling and release as two steps: schedule to see the plan, release to commit the plan, and hold work back until the floor is ready for it. The payoff is shorter queues, shorter lead times, and a floor where the next job is obvious. See how start dates and priority shape what reaches the floor in EDGEBIC, and read the full sequencing pipeline in the scheduling engine guide.