Time fence or time freeze — which one is deleting your…

Time fence or time freeze — which one is deleting your planners' work?

Two features in the Dynamics 365 demand planning app have near-identical names and precisely opposite jobs. One stops people editing a forecast. The other stops the engine overwriting what people edited. If your planners' manual adjustments keep vanishing after a rerun, you are missing the second one — and no amount of the first one will bring them back.

The answer, before anything else

**[Time fence](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/time-fences) [GA]** — What it prevents: Manual editing of time series values inside a date span · What it constrains: People, and the rule can differ by security role · Where it applies: Every time series where the rule's logic is true
**[Time freeze](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/time-freeze) [GA]** — What it prevents: The forecast recalculation overwriting existing values · What it constrains: The calculation itself · Where it applies: Only the forecast steps you explicitly assign it to

Read the third column twice. A time fence protects an agreed number from your planners. A time freeze protects a planner's number from the next run. They are not two settings of one idea, and an implementation needs both for different reasons.

What each one prevents, in Microsoft's own words

Do not reason from the names. Microsoft's two pages state the distinction explicitly, and each one names the other:

Time fences let demand planning managers define rules that prevent users from manually editing

time series values that are associated with a specified time span. … However, time fences only

prevent manual updates.

— Limit manual time series edits with time fences

Time freezes let planners define rules that prevent the system from automatically updating

selected cells in existing time series when a forecast gets recalculated … However, time freezes

only prevent automated updates that would otherwise occur when you rerun a forecast; users can

still edit those values manually in the time series.

— Limit automatic time series updates with time freezes

The last clause of each page is the tell. A time fence leaves the recalculation completely free. A time freeze leaves the planner completely free. They also arrived as separate releases on the demand planning app's own version line — time fences in version 1.0.0.1281, time freeze rules in version 1.0.0.2502, per Microsoft's what's-new page. They were never one feature.

The asymmetry that actually deletes the work

The names are a nuisance. The default behaviour is the defect. Microsoft states it plainly on the time freeze page:

Unlike time fences (which apply to all time series that match the time fence logic), you must

explicitly configure each relevant Forecast and Forecast with signals step to use the time

freezes that should apply to it. You can assign any number of time freezes to each step, and you

can also assign no time freezes at all. If you don't assign any time freezes to a step, then the

step won't use any time freeze rules.

— time-freeze

A time fence is ambient: create the rule and it binds wherever its logic is true. A time freeze is opt-in, per step, per profile. A forecast profile that nobody has revisited since go-live has no freeze on it, and every cell in it is fair game on the next run.

**Reach once the rule exists** — Time fence: All matching time series · Time freeze: Nothing, until assigned to a step
**Assigned on* — Time fence: Nothing to assign · Time freeze: Each Forecast or Forecast with signals* step
**Role-aware — Time fence: Yes — a Role edit tab and a Select roles** wizard page · Time freeze: No role step is documented in Microsoft's procedure
**Dimension-aware** — Time fence: Yes — conditions over table, column, operator, value · Time freeze: Yes — the same condition builder
**Overlap resolution** — Time fence: Documented: "the more specific condition applies" · Time freeze: Not stated on the page
**Created at — Time fence: Configuration > Time fences · Time freeze: Configuration > Time freezes**

The role row is the one worth arguing about internally. Microsoft's example is exact: "a role-based time fence rule might allow managers to edit a forecast in a period that planners can't edit." That is a governance control and it belongs to the fence.

There is also a second kind of freeze that needs no rules at all. Demand planning version 1.0.0.3424 added Freeze manual adjustments — on the time freeze page, "a simple on/off setting that you can enable for each Forecast and Forecast with signals step" which "prevents automatic updates to any time series cells that have been manually adjusted by a user." If planner judgement is the only thing you are protecting, that is the shortest route to it, and it sits in the Freeze values section of the step settings beside the Enable time freeze checkbox.

The trap both of them share

Both features bind to a time bucket size, and neither converts. From the time fence page:

The time fence applies only to time series that also use this time bucket size. The system doesn't

convert between time bucket sizes. For example, if you select Monthly here, your rule doesn't

apply to time series that use Weekly time buckets (even though a month is about four weeks long).

The freeze page carries the same warning in near-identical wording, adding that a monthly rule "won't be available" to models in profiles that use weekly buckets. A correctly written rule can therefore be invisible rather than wrong. Forecast monthly at the top and weekly at SKU (stock-keeping unit) level and you need the rule twice; nothing will tell you that you wrote it once.

Where Microsoft's own pages do not settle it

Two things, and we are not going to resolve either from the outside.

Who owns a freeze is stated three different ways. The time fence page says time fences are defined by "demand planning managers". The time freeze page says time freezes let "planners" define rules. The what's-new entry for the same feature says "Time freeze rules let demand planning managers establish policies". Manager, planner, manager. No page states the permission model behind the difference, so treat the actor as a decision your security design makes rather than one the product has made for you.

And the time fence page names the wrong feature inside its own procedure. Step 3 of Manage time fences reads: "If you choose to create a new time freeze, then a wizard launches, which offers similar settings." We report it not to score a point but because if Microsoft's own editors slipped between these two words inside their own procedure, your configuration notes will too.

What to do this week

Open Operations > [Forecast profiles](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/forecast-profiles), take each profile in turn, open the Forecast model tab, open Settings on every Forecast and Forecast with signals step, and record whether Enable time freeze is ticked. That count is your actual exposure.
For every step where it is not ticked, decide between Use time freeze rules and Freeze manual adjustments. The second needs no rule records and covers the common case.
Open Configuration > Time fences and check the Time buckets value on each rule against the bucket size of the profiles you actually run. Mismatches are silent.
Run one profile against an existing time series with a deliberate manual adjustment in it, then read the Explainability tab of the resulting job run — reached from the profile's Jobs tab via the Job run name link, per Microsoft's forecast profile documentation. That is where you find out what the engine did, rather than what you configured.

Where we would draw the line

We would not rebuild either lock outside the app. Both are governance primitives on the vendor's own surface, and anything we wrote alongside them would be a second policy store that disagrees with the first one inside a quarter.

What we optimize is the decision underneath: which items deserve a planner's manual adjustment at all, and which should be left to the calculation because a human touch on them adds noise rather than signal. Dynamics manages the lock; the segmentation that decides where a planner's scarce attention is worth spending is a data-science decision the ERP records but does not make.

That is this cluster's argument in miniature, and the pillar behind it is dynamics-365-mrp-inventory-still-wrong: master planning is a calculation, not a decision. It executes the policy you gave it — and a lock nobody assigned is a policy nobody set. Two neighbouring chapters carry the rest: forecast-double-counting-dynamics-365 for what master planning does with the forecast, and forecast-algorithm-intermittent-demand for which calculation is producing the numbers your planners are adjusting.

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 your planners' adjustments are disappearing and you want a second pair of eyes on the profile configuration, book a call and we will walk your forecast steps with you. https://cognilium.ai

Time fence or time freeze — which one is deleting your planners' work?