A client I spoke with last month runs three distribution centers and had built twenty-two separate work templates just to route outbound work by carrier, shipping deadline, and pick zone. Nobody had designed it that way on purpose. It grew one exception request at a time, until the warehouse team could no longer explain why template seventeen existed or what would break if someone deleted it. Then Supply Chain Management 10.0.49 shipped in September 2026, and dynamic work classification rules, which had been sitting in feature management as a production-ready preview since June, switched on by default. Nobody flipped that switch deliberately. It just happened, and now every one of those twenty-two templates is technically obsolete even though none of them have been touched.

That is roughly the position a lot of warehouse teams are in right now, whether or not they knew this feature existed. Understanding what a Power Fx formula here can and cannot do is the difference between quietly benefiting from a real simplification and quietly breaking work assignment logic nobody remembers building.

What Dynamic Work Classification Rules Replace

The traditional approach to routing warehouse work in D365 Supply Chain Management has always been template proliferation. Every combination of conditions, say three carriers crossed with two shipping windows crossed with four pick zones, has historically meant a separate work template with its own pool assignment, priority, and location directive setup. It works, but it fails quietly: someone adds a fourth carrier, forgets to clone the templates correctly, and outbound work for that carrier silently inherits default priority instead of being expedited.

Dynamic work classification rules collapse that structure into a single work template plus a Power Fx formula that evaluates conditions at the moment work is created, and optionally again when the underlying load changes. Instead of a template per carrier, one rule with a Switch statement handles all three:

Switch(workTable.Load.CarrierCode,
    "Carrier1", {WorkPoolId: "Carrier1", DefaultWorkPriority: 100},
    "Carrier2", {WorkPoolId: "Carrier2", DefaultWorkPriority: 50},
    "Carrier3", {WorkPoolId: "Carrier3", DefaultWorkPriority: 10}
)

That single formula does the job of three templates, and when a fourth carrier gets added, it is one more line in a Switch statement rather than a cloned template someone might configure incorrectly.

Two Points Where the Formula Actually Runs

The mechanics matter here because they determine what data a rule can see. A classification rule has a scope, and the scope is either "Work" or "Work and initial work lines." A work-scoped rule runs once, after the work header itself is created, and it can only reference header-level objects: the work record, its associated load, shipment, wave, and any transportation management appointment tied to it. That is enough for the carrier and deadline examples above, because carrier code and shipping schedule live on the load.

A rule scoped to work and initial work lines runs twice: once for the initial pick line, where it has access to line-level data including the item master record, warehouse-specific item settings, and the pick zone, and again at the header level using the same objects a work-scoped rule sees. This matters when classification depends on something below the header, such as routing freezer-zone picks to a restricted work class that only certified workers can claim, which requires referencing workLine.ZoneId, a field only available at the initial-line evaluation.

Picking the wrong scope is a common early mistake. A rule written to reference workLine fields will simply fail or return blank values if it is configured with "Work" scope, because that data object was never in scope for the formula to read from.

Reading Blank and Empty String Correctly

The formula's return values control four fields on the work header: the work pool ID, a numeric default work priority, a set of location directive code overrides, and, for line-scoped rules, work class overrides. The distinction that trips up almost everyone writing their first rule is what happens when a field is omitted or explicitly cleared.

Returning Blank() for a field, or simply leaving it out of the returned record, tells the system to preserve whatever value the work template already had configured. Returning an empty string actively clears that value. These look similar on a quick read of a formula, but they produce opposite outcomes, and the difference is invisible until a load hits an edge case the formula author did not anticipate and the work pool field ends up wiped instead of defaulted. Anyone porting logic from a spreadsheet of business rules into Power Fx should treat this distinction as a required review step, not a detail to catch during testing.

Time-based priority formulas are where this feature earns its keep beyond simple carrier routing. A formula that reads a load's scheduled ship time and converts it into a same-day numeric priority, nine in the morning becoming priority 900 and three in the afternoon becoming 1500, while pushing anything scheduled for a future date to a flat low-urgency value, replaces what used to require either a batch job recalculating priorities on a schedule or a set of static templates keyed to time windows that someone had to remember to update every quarter.

The Reclassification Setting That Determines Whether This Helps or Hurts

The warehouse management parameter setup has a field called "Work classification on load update" with two practical states: disabled, meaning rules fire once at work creation and never again, and synchronous, meaning any load change, a carrier reassignment being the obvious case, triggers an immediate reclassification of every work record tied to that load before the user's screen returns.

Synchronous reclassification is correct in low-volume environments where a carrier reassignment genuinely should re-route work immediately. In a high-volume distribution center running continuous wave releases, setting this to synchronous means a single load correction by a transportation coordinator can trigger a reclassification pass across hundreds of work records in the same transaction, and that user experiences the delay directly. Time-based priority formulas compound this: if a formula depends on current time rather than a fixed schedule value, it needs recalculating on a recurring interval rather than only on load events, pushing the design toward a scheduled batch job instead of synchronous evaluation. Teams that enable this feature without deliberately choosing this setting are, by default, accepting whatever behavior comes pre-configured, which is not necessarily what their volume can tolerate.

Migrating Off Template Sprawl Without Guessing

The practical migration path starts with the Preview function built into the rule editor, which evaluates a candidate formula against existing work headers without committing any changes, letting a solution architect validate logic against real production data before it goes live. The Copy function on existing rules turns a working formula into a starting point for the next variation rather than requiring every rule to be written from scratch.

The one alignment check that gets skipped most often is making sure work template grouping settings match what the formula actually classifies on. A rule that assigns work class based on pick zone only makes sense if the underlying work template groups work so that each header contains lines from a single zone. If the template grouping mixes zones within one work header, a zone-based classification formula is evaluating against a header that spans multiple zones, and the result will not reflect the intent of the rule. This is a configuration mismatch, not a Power Fx defect, and it will not surface as an error, only as classification results that look wrong for reasons that are not obvious from the formula itself.

There is also no built-in mechanism for chaining multiple rules or setting rule priority across rules. Only one dynamic work classification rule can be attached to a given work template, so any scenario requiring multiple conditional layers has to be built as nested logic within a single formula rather than as a stack of separate rules evaluated in order. Teams used to unified routing's classification rulesets in Customer Service, where multiple rulesets and conditions can be layered, will find this a meaningfully different mental model, and formulas that try to replicate that layered structure will need to do it with nested If and Switch statements rather than rule ordering.

Where This Actually Pays Off

The twenty-two-template warehouse from the opening is not a rare case. Template sprawl is what happens by default in any warehouse operation that has been live for more than a couple of years and has accumulated exception handling one request at a time. Dynamic work classification does not eliminate the need to think through routing logic, but it moves that logic into a formula that a single person can read end to end, version, and test against real data before deployment, rather than a folder of templates whose relationships to each other exist only in institutional memory. Getting the scope, the Blank-versus-empty-string distinction, and the reclassification timing right the first time is what determines whether that consolidation actually reduces operational risk or just relocates it into a formula nobody has reviewed yet. Routeget's warehouse implementation work increasingly starts with exactly this kind of template audit, because the fastest way to write a good classification rule is to first understand precisely which decisions the old templates were actually encoding.

---

#DynamicsSCM #WarehouseManagement #PowerFx #WarehouseAutomation #SupplyChainOptimization