Should master planning use finite or infinite capacity?

Plan infinite everywhere, finite on the constraint, and put a rough-cut check in between. That is our position, not Microsoft's, and it exists because the alternative — switching finite capacity on globally in week one — fails for reasons Microsoft's own documentation states in plain sentences.

What each one actually does

**Finite capacity** — Microsoft's own description: "Finite capacity is an approach that helps you understand how much work can be produced during a specific period when limitations on different resources are taken into consideration" · Consequence for the plan: "If there isn't enough capacity on the resources, the delivery date is pushed out, and the job is scheduled when there's enough capacity"
**Infinite capacity* — Microsoft's own description: The Infinite capacity scheduling for Planning Optimization* feature "introduces scheduling that is based on route information" and "supports the most common functionality that is required for manufacturing scenarios" · Consequence for the plan: A resource set to infinite "is assumed to have infinite capacity, and the resource might therefore be overbooked"
**Capability-based selection** — Microsoft's own description: "A capability is the ability of an operation resource to perform a specific activity" — you "defer resource allocation until orders are scheduled" · Consequence for the plan: The engine picks the resource at schedule time from those that satisfy the requirement

Sources in order: Finite capacity planning and scheduling, Scheduling with infinite capacity, Operations resources and Scheduling with resource selection based on capability.

Note the asymmetry in that table. Finite capacity moves a date. Infinite capacity moves nothing — it produces a schedule that respects route structure and sequence but not availability. Neither is "more correct". They answer different questions, and most plants need both answers at once.

What Planning Optimization supports

Finite capacity is supported. Microsoft's Planning Optimization fit analysis lists "Resources scheduled with finite capacity" against the explanation "This feature is now supported." Routes in planning are supported likewise.

One exception matters, and it is the one that surprises people migrating from the deprecated master planning engine [DEPR]:

"Finite capacity planning and scheduling works in nearly the same way, regardless of whether you use

Planning Optimization or the deprecated master planning engine. However, Planning Optimization

doesn't use the Bottleneck time fence parameter. When you use Planning Optimization, bottleneck

resources are always scheduled by using the same time fence as non-bottleneck resources (as

indicated by the finite capacity time fence)."

The corresponding entry on Microsoft's parameters-not-used list is blunter: "Capacity time fence for bottleneck resources – Planning Optimization doesn't support this parameter because customers didn't use it." Microsoft's Operations resources page states the condition on the flag itself: "A bottleneck resource is scheduled by using finite capacity when the Finite capacity and Bottleneck scheduling options on the Master plans page are selected." What the parameters-not-used list settles is narrower — the separate horizon is unsupported. Neither page states whether the flag's own routing survives under Planning Optimization.

Four documented limitations apply to infinite scheduling under Planning Optimization [GA]. Microsoft lists them as: the feature "supports only infinite capacity"; it "doesn't support resource load functionality"; it "doesn't consider route scrap"; and it "supports Duration only as the primary resource selection".

That last one is worth pairing with the capability page, which describes resource selection by Priority as conditional on "Priority is selected in the Primary resource selection field on the Scheduling parameters page". Read together — and this reading is ours, not a sentence Microsoft writes — priority-based resource selection is not the lever you have under infinite scheduling in Planning Optimization. Confirm it in your own environment before designing around it.

The three switches, and all three are required

**Capacity planning, globally — Path: `Master planning > Setup > Master planning parameters` · Setting: Planned orders tab, Capacity planning section, set Production* to Yes*
**Finite capacity, per plan — Path: `Master planning > Setup > Plans > Master plans` · Setting: General FastTab, Planned production orders section, set Finite capacity* to Yes*
**Finite capacity, per resource — Path: `Production control > Setup > Resources > Resources` · Setting: Operation FastTab, Capacity button section, set Finite capacity* to Yes*

Every path above is copied from Microsoft's finite capacity page. The design point is the third row: finite capacity is a per-resource decision that a plan-level switch merely permits. That is exactly the shape our position needs — you are supposed to be selective.

The capacity time fence is the control

The concrete lever between "everything is finite" and "nothing is" is the capacity time fence, on the Time fences in days FastTab of the Master plans page. Microsoft's definition:

"The capacity time fence indicates how far in the future the system considers the maximum capacity of

your resources when it schedules orders."

And the sentence that makes it a rough-cut mechanism rather than a performance dial:

"If the requirement date for a planned production order is outside the capacity time fence, the lead

time is determined by the delivery time of the item."

So beyond the fence the plan is already infinite in effect, and it uses item lead time. Inside the fence it schedules against the route and resource capacity. Setting that boundary is a policy decision about how far ahead your capacity data is trustworthy — which, in most plants, is a much shorter horizon than the planning horizon.

Microsoft's own caution on the fence used in its worked examples is worth quoting because it is unusually direct: "In reality, a single-day time fence is probably too low for most manufacturers that use finite capacity planning."

Why enabling finite everywhere on day one fails

Finite scheduling consumes master data that is almost never correct at go-live. Four fields decide the answer, all on the Resources page:

**Capacity** — "Specify the operations resource's capacity per hour in terms of the capacity unit of measure"
**Efficiency percentage* — "adjusts the throughput of the operations resource and affects the time that is reserved for the resource… Scheduling time = Time × 100 ÷ Efficiency percentage" — and "Time* includes both the run time and setup time"
**Operations scheduling percentage** — "Specify the maximum percentage of capacity of the operations resource that you want to use in operations scheduling"
**Finite capacity* — Set to No*, "the operations resource is assumed to have infinite capacity, and the resource might therefore be overbooked"

Add calendars. Microsoft warns that if there are no effective working calendars for a resource group, "you can no longer access the operations resources that are assigned to the resource group for production planning and operations scheduling." An expired calendar does not degrade the schedule; it removes the resource from planning.

Then there is the sentence that decides it for a large share of discrete manufacturers, and Microsoft wrote it, not us:

"If your capacity can change as requirements change (for example, when you're working with shifts),

you shouldn't use finite capacity functionality, because the calculated processing times won't be

correct."

If you flex a second shift when the order book fills, finite capacity everywhere is documented as the wrong choice. That is not an argument against finite scheduling on your press line. It is an argument against the global switch.

Where capability-based selection helps, and where it stops

Capability requirements let you write the route once and let the engine choose. Two behaviours are worth knowing before you commit to them. Expiry is silent: "the system won't use a resource or capability that has an expired capability assignment, even if that resource otherwise satisfies the requirements." And availability beats priority: "during backward scheduling, if a resource with a high priority isn't available (for example because its calendar is closed) then another resource would be chosen."

Human-resource requirements are the boundary. Microsoft's note on the infinite scheduling page: "Requirements that are related to human resources, such as skills or certificate requirements, aren't yet supported." The fit analysis lists "Planning Optimization support for requirement types skills, courses, certificates, and titles" with the explanation "This scenario isn't yet supported" and an estimate of Future wave. That estimate is not a release-plan commitment — it does not appear in the Dynamics 365 Supply Chain Management 2026 release wave 1 plan, which covers April 2026 through September 2026 — and Microsoft flags the whole column as "subject to change without notice."

The counter-argument

"If finite is more realistic, run it everywhere and fix the data." Fair, and it is the honest long-term destination. Two things make it the wrong first move. Finite scheduling turns every master data error into a moved delivery date, so the plan becomes untrustworthy in the same week the team is trying to learn to trust it. And it inverts the debugging order: with infinite planning a capacity problem shows up as a load you can look at, while with finite planning it shows up as a date, and dates hide their causes.

What to do this week

List the resources your plant actually queues behind. In most discrete plants it is one to three, and everything else is noise dressed as capacity.
Read the capacity time fence on the plan you run, and ask how far out your calendars and efficiency figures are genuinely maintained. Where those two numbers disagree, the fence is wrong.
Check every resource group for an unexpired working calendar before you touch anything else.
Turn Finite capacity on for the constraint resources only, leave the plan-level switch on, and compare one run against the previous infinite run before widening.

Where we would draw the line

We would not enable finite capacity globally in a first planning go-live. We would not use finite scheduling at all on a site that flexes shifts against the order book, because Microsoft documents that the calculated processing times will not be correct. And we would not build a capacity optimization layer on top of a plan whose resource calendars and efficiency figures nobody owns — the optimizer would be scheduling against fiction, precisely and repeatedly.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are deciding where the finite boundary sits in your plant, book a call and we will walk your constraint list and your capacity time fence with you. https://cognilium.ai

Should master planning use finite or infinite capacity?