Why does your MRP produce twelve thousand action messages?

Because you asked it to. The volume is an output of your coverage configuration, not a measurement of how wrong the plan is. Four settings decide the count, Microsoft documents every one of them, and every one is a policy decision left to you.

The number measures your configuration, not your accuracy

Microsoft's definition is narrow and worth reading slowly. An action message is "a system-generated suggestion to change an existing planned, approved, or firmed order", and the calculation "generates action messages in response to changed requirements."

Nothing there is about correctness. Two plans built by the same engine from the same data can differ by an order of magnitude in message count, purely on what the coverage groups were told to report. Master planning [GA] is a calculation; the policy it executes is yours.

So the right key indicator for a planning implementation is not forecast accuracy and not plan stability. It is action messages per planner per day — a number you can count before lunch, and one a planner recognises as their actual working life. That indicator is ours, not Microsoft's.

Start by knowing what you switched on. Microsoft lists exactly what you can select on the **Coverage groups** page:

**Advance — What Microsoft documents it does: Moves orders "to an earlier date" · The setting that suppresses it: Advance margin** — "the maximum number of days that can pass between a receipt and an issue without an advance action"
**Postpone — What Microsoft documents it does: Moves orders "to a later date" · The setting that suppresses it: Postpone margin**, defined the same way
**Increase** — What Microsoft documents it does: Receipts "should be increased to prevent shortages in inventory" · The setting that suppresses it: Default order settings — the system "never causes undersupply"
**Decrease** — What Microsoft documents it does: Receipts "should be decreased to prevent excess inventory levels" · The setting that suppresses it: Never below the quantity needed for safety stock
**Derived actions** — What Microsoft documents it does: Propagates receipt actions "to any derived requirements" · The setting that suppresses it: Switch it off and multi-level BOM noise stops multiplying

Two of the five have a suppression margin. Most implementations leave both at zero, then wonder why a one-day movement generates a message.

Lever one: forty thousand items should not share one policy

Microsoft's fallback is explicit: "if you don't link a coverage group to a product, master planning uses the general coverage group that you specify on the Master planning parameters page" (coverage settings). The default state is one policy for everything, and the default state is the loudest one available.

Take a distributor running forty thousand items in a single coverage group. Every fastener inherits the reporting sensitivity of every programme part. The engine is right every time and the planner reads none of it.

The segmentation below is our method, not Microsoft guidance — Microsoft publishes the settings, not the matrix. Rank items on two axes: value, by annual consumption value, and demand variability, by the coefficient of variation of period demand. The starting points are ours, and they are starting points.

**High value, steady demand* — The item it describes: Programme parts, contracted volumes · Coverage code we start from: Requirement* · Action messages: On, with tight advance and postpone margins
**High value, erratic demand* — The item it describes: Configured items, project material · Coverage code we start from: Requirement* · Action messages: On — this is the segment a planner should read
**Low value, steady demand* — The item it describes: Runners, consumables · Coverage code we start from: Min/Max* · Action messages: Off
**Low value, erratic demand* — The item it describes: Fasteners, packaging · Coverage code we start from: Min/Max* · Action messages: Off
**Being phased out* — The item it describes: Obsolescing service parts · Coverage code we start from: Manual* — the system "doesn't suggest purchase, transfer, or production orders" · Action messages: Off

Microsoft also gives one grouping rule that most segmentations break: "items in the same coverage group should have similar lead times". A group holding a two-day fastener and a sixteen-week casting cannot have a correct negative-days value, which is the next lever.

Lever two: negative days, where two Microsoft pages disagree

Negative days set how late a receipt is allowed to be before the engine gives up and creates new supply.

Microsoft's master plans overview states the volume effect plainly — "If you set the negative days to a high number, the system generates lots of action messages" — then advises: "Set the negative days to a number that's less than the lead time of the item."

The dedicated negative days article concludes the opposite: "it's a good idea to set the negative days to a number that is more than the lead time of the items in the coverage group."

Both pages are live and they contradict each other. We are not going to tell you which is right; here are the two things not in dispute. First, the setting trades message volume against delivery risk, and the negative days article walks both ends of it — set it low and "MRP must create a new planned order, and must calculate delays and actions"; set it high and "you must analyze and apply the action messages" (negative days, case 1A and Conclusion).

Second, on the current engine the toggle argument is over. Planning Optimization [GA] — the add-in that now performs master planning — ignores the Use dynamic negative days parameter entirely, because it "always uses the *Dynamic negative days* approach".

Your number is one term in a formula that also carries the item's lead time and the gap between today and the requirement date. Tuning it without knowing that is guessing.

Lever three: the time fences, and there are more than you think

Microsoft's master plans overview documents these settings on the Time fences in days FastTab: Coverage, Freeze, Firming, Forecast plan, Capacity, Action message, Calculated delays, Approved requisitions time fence and Sequencing — nine.

A second Microsoft page, parameters not used by Planning Optimization, names a tenth on the same FastTab, Continuity plan, and says Planning Optimization does not support it.

Three of them change your message count directly.

Action message caps how far forward messages are generated at all, "calculated forward from the current date."
Freeze changes who gets messages. Microsoft: "The system only creates action messages for unapproved planned orders while they're within the freeze time fence. Outside of the freeze time fence, the system only creates action messages for approved planned orders and firmed orders." The freeze fence is honoured by Planning Optimization through the Freezing time fence for Planning optimization feature, on by default from version 10.0.43.
Coverage decides what enters the engine. Microsoft designed it for exactly this problem: coverage time fences "help prevent 'noise' caused by supply suggestions that don't require attention for months" (coverage time fences). The default value is one hundred days.

One rule underneath all of them: the master plan wins. "The time fences you select on this page override the time fences defined in the coverage group." Segment all you like — a master plan with its own fences set to Yes has overruled you.

Lever four: switch it off where the answer is always "do nothing"

This is the lever nobody pulls, and Microsoft publishes the instruction. On the Master plans page, "set the Action message time fence to 0 (zero) for the master plan that you're running. Also make sure that the Action message setting is turned off for all the coverage groups." Microsoft's stated reason is runtime: "The calculation of action messages causes a longer running time for master planning."

There is a second, blunter route. Under the Priority coverage code [GA], Microsoft states: "The system doesn't generate action messages for coverage codes with priority-based planning."

Replenishment is driven by where stock sits between the Minimum, Reorder point and Maximum values instead of by date-based exceptions. That is a policy change, not a mute button — which is why we put it on C-parts (low-value, high-volume consumables) and nowhere else. That placement call is ours, not Microsoft's.

"Turning actions off hides real problems"

It is the right objection, and what stays on answers it. Delays are not optional under Planning Optimization: Microsoft lists Calculated delays among the parameters it ignores "because it always calculates delays for the coverage group." A late supply still surfaces as a delay whether or not anybody asked for a postpone message.

The failure the objection describes comes from switching messages off on the wrong segment — the expensive, erratic, single-source items where a human genuinely has to decide. Nobody should be reading advance messages on packaging tape.

What to do this week

Count. Group your open action messages by planner and by coverage group. The distribution, not the total, tells you which group to fix first.
Open every coverage group and write down its Advance margin and Postpone margin. If they are zero, that is a decision nobody made.
Check whether any master plan has its own time fences set to Yes, and compare each to the coverage group it overrides.
Split the noisiest group by lead time first, then by value. Microsoft's grouping rule does most of the work before you reach the matrix. If the group is still too large to plan comfortably, plan filters and runtime filters narrow the run itself.

Where we would draw the line

We would not switch action messages off on any item with a single source of supply, however cheap — the message is the only warning before a line stops. We would not raise negative days to quiet a group whose lead-time spread is still wide; that hides shortages instead of resolving them. And we would not tune any of this against a message count alone. The count is the symptom; the policy is what you are changing.

Dynamics 365 manages replenishment. Choosing the policy per item — which code, which margins, which fence — is the optimization it leaves to you, and it is what Demand & Inventory Optimizer does: it segments the catalogue on live demand and lead-time behaviour and writes the coverage policy back into Dynamics behind an approval step, so the segmentation stops being a spreadsheet somebody made once.

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/

Worked example. Modelled from public documentation and typical operations.

Counting action messages per planner takes an afternoon and it will tell you which of the four levers you are missing. Book a fifteen-minute call and we will walk your coverage groups with you, live — no deck. https://cognilium.ai

Why does your MRP produce twelve thousand action messages?