Finite vs infinite capacity in D365: delivery dates you can defend

The symptom: the same line booked three times in one shift

Sales promises a date straight out of the ERP. Production looks at it and shakes their head. It's usually not a master-data problem, and rarely a routing problem: it's the planning model. With infinite capacity, the master plan loads every resource without asking whether there's room — the same line can end up booked three times in the same shift, and nobody notices until the plan hits the floor.

The real cost isn't technical: it's credibility with the customer. One missed date can be explained; a steady stream of missed dates becomes the company's reputation.

What infinite-capacity planning actually does

The default for almost every master plan is to calculate requirements and schedule operations assuming unlimited capacity: any resource can absorb any load, at any time. It's fast, simple, and for some businesses even correct — if capacity is genuinely abundant or flexible (easy overtime, instant subcontracting), the approximation holds.

The problem shows up in complex manufacturing: real bottlenecks, long changeovers, unique resources. There, the infinite-capacity assumption isn't an approximation: it's a structural lie the system repeats on every planning run.

Finite capacity flips the logic

With finite capacity, scheduling accounts for capacity already reserved by other operations. If the resource is full, the operation slips — and with it, the date promised to the customer. Planning Optimization in D365 F&SCM supports this natively: you enable it per resource (not across the whole plant) and combine it with backward scheduling from the requested date, so capacity conflicts surface at planning time, not after production has started.

The result isn't more capacity — no system invents that. It's dates you can defend in front of the customer, because they're built on the real load of your resources.

The price: slower runs, more discipline

Finite capacity has a cost. The calculation is heavier, planning runs get longer, and switching it on indiscriminately turns your master plan into a crawl without adding useful precision. The three moves that make the difference:

• Enable it only on bottlenecks. The finite-capacity flag lives on the individual resource: the one-of-a-kind press yes, the easily duplicated assembly bench no. 80% of the benefit comes from 20% of the resources.
• Tune the capacity time fence. Beyond a certain horizon, finite-capacity scheduling is statistical fiction: find the shortest horizon that supports your commercial promises and stop the heavy calculation there.
• Use backward scheduling from the requested date. The system starts from the delivery date and works backwards: if the capacity isn't there, the conflict surfaces immediately — while you can still choose between overtime, subcontracting or renegotiating the date.

When NOT to use it

Finite capacity amplifies the quality of the data you feed it. If routings and changeover times are five-year-old estimates, the system will schedule wrong dates with surgical precision. Fix the routing data on critical resources first, then switch on finite capacity — not the other way around.

And if your capacity is genuinely flexible — on-call overtime, subcontractors on standby, elastic shifts — infinite capacity with good load monitoring can remain the right choice. You pick the model based on your factory, not the brochure.

Where to start

The sequence I use on projects, in order:

• Identify your 3-5 real bottlenecks (ask the shop floor, not the system).
• Verify routings and resource calendars on those resources: stale data makes everything else pointless.
• Enable finite capacity only there, with a short time fence (2-4 weeks to start).
• Measure for a month: promised vs met dates, before and after. The delta is your business case.