--- title: "Power Fx is in the warehouse execution path. What does dynamic work classification decide?" canonical_url: "https://cognilium.ai/blogs/power-fx-dynamic-work-classification" slug: "power-fx-dynamic-work-classification" section: "blogs" date_published: "2026-08-03" date_modified: "2026-08-03" word_count: 1680 reading_time_minutes: 7 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" entities: [] related: [] --- # Power Fx is in the warehouse execution path. What does dynamic work classification decide? A Power Fx formula now overrides work pool, work priority, location directive codes and work classes at work creation. Its own page names the feature Production Ready Preview, and the release plan agrees once you read the legend — public preview carries a check mark and a full release date, general availability a bare month and none. Previewed, not generally available, on by default from 10.0.49. ## Key takeaways - A Power Fx formula evaluated at work creation can override the work pool, the work priority, location directive codes and work classes on the generated work, so one template plus one rule replaces several static templates. - The work class override applies only to the second and subsequent pick and put pairs, and changing the first pair requires a separate initial work line formula on the same rule. - Returning blank or omitting a field preserves the work template's value while returning an empty string clears it, which makes two visually similar expressions behave in opposite ways on live work. - A zone-based formula depends on the work template grouping work by zone, so the formula's correctness rests on a work header break configured in a different screen. - Two rule settings are documented as reserved for future use with no effect in the current release, while a published example states that its approach needs a recurring reclassification job — so read both before designing around either. ## Power Fx is in the warehouse execution path. What does dynamic work classification decide? A Power Fx formula now runs at work creation and overrides four things about the work your pickers receive. That is a low-code expression inside a warehouse execution path, worth understanding before somebody discovers it and starts writing formulas. ## What it decides: four fields, at runtime, instead of many templates [Dynamic work classification](https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/dynamic-work-classification) `[PRP]` (`ms.date` **2026-07-27**) states the problem it exists to solve: > "Without dynamic classification, each combination requires its own work template, which can lead to a large and complex configuration." > "When warehouse work is created, the system evaluates a Power Fx formula to override the work pool, work priority, location directive codes, and work classes on the generated work. The formula can look up values from the work header and associated records, including the load, shipment, wave, and transportation appointment." There is a second capability, reclassification: "If a load changes after work has been created (for example, the carrier is reassigned), the system can reevaluate the formula and update the associated work." So one work template plus one rule can do what several used to. Chapter 5 is the static version of these decisions. ## Its status looks like two answers. The release plan's own legend gives you one This is the part to get right, because two pages describe the status and people quote whichever they found. They agree — but only if you read the legend. - The feature's own documentation (`ms.date` 2026-07-27) — The feature "named *(Production Ready Preview) Dynamic work classification* must be turned on in feature management. As of Supply Chain Management version 10.0.49, this feature is turned on by default." - The [2026 release wave 1 plan](https://learn.microsoft.com/en-us/dynamics365/release-plan/2026wave1/enterprise-resource-planning/dynamics365-supply-chain-management/planned-features) (`ms.date` 2026-07-28) — Row "[Automate dynamic work classification with Power FX]" shows **Public preview** with a check mark and **Apr 24, 2026**, and **General availability** reading **Jun 2026** with **no check mark** The legend decides how to read those columns, in two sentences. On dates: "In the **General availability** column, the feature will be delivered within the month listed… Released features show the full date, including the date of release." And on the symbol: "This check mark … shows which features have been released for public preview and general availability." Apply both. **Public preview** carries a check mark and **Apr 24, 2026** — a full date, so released. **General availability** carries **Jun 2026**, a bare month with no check mark, so not released, whatever the calendar says. **Which is exactly what the feature's own page says.** The string in feature management reads *(Production Ready Preview)*. The two pages are not in conflict; they report one status through two artefacts, and the legend makes them line up. So: `[PRP]`, on by default from 10.0.49, and the general-availability month is not a date to plan a cutover around. Two smaller things from the same pages. The version floor is plain — "You must be running Microsoft Dynamics 365 Supply Chain Management version 10.0.48 or later" — and the release plan describes itself as listing "features that are planned to release from April 2026 through September 2026". Microsoft also spells it differently across the two pages: *Power Fx* on the product page, *Power FX* in the release-plan title. Both reproduced as found. ## The four override fields, and the one that skips your first pick and put - `WorkPoolId` — Type: String · What Microsoft says it does: "Overrides the work pool on the created work." - `DefaultWorkPriority` — Type: Number · What Microsoft says it does: "Overrides the priority on the created work." - `DirectiveCodeOverrides` — Type: Record · What Microsoft says it does: Each field name is a directive code to replace, the value is the new one. "Applies to all pick/put pairs." - `WorkClassOverrides` — Type: Record · What Microsoft says it does: Each field name is a work class to replace. "Applies **only to the second and subsequent** pick/put pairs. To change the work class of the first pick/put pair, use the initial work line formula instead." Read the last row twice. **The obvious formula does not touch the first pick and put** — which for most outbound work is the pick that matters. The mechanism is a second formula. Set **Rule scope** to *Work and initial work lines* and the rule gains an **Initial work line formula** FastTab, which runs "as the first pick work line is assigned to a new work record" and can override `WorkPoolId` and `WorkClassId`. Practically: **the work class on your first pick line and the work class on the rest are set by two different formulas**, and missing that produces a rule that half works. The data a formula can reach is published as objects: `workTable` plus `.Load`, `.Shipment`, `.Wave` and `.Appointment`; the initial work line formula reaches `workLine` and its item and load records. ## Blank preserves. An empty string clears. > "Returning `Blank()` for a field (or omitting it) preserves the original value from the work template. Returning an empty string (`""`) actively clears the value. For example, returning `Blank()` for `WorkPoolId` keeps whatever work pool was set on the work template, while returning `""` removes the work pool entirely." Two expressions that look interchangeable to anyone who has not read that paragraph, with opposite effects on live work. A formula returning `""` on an untested branch strips the work pool. ## The grouping dependency, and it is chapter 5's setting > "When you use dynamic work classification with a work template, make sure the template's grouping settings align with your formula logic. For example, if your formula classifies work based on zone, the work template should group work creation by zone so that each work header contains lines from only one zone." That is **Work header breaks**, which chapter 5 covers. The dependency runs both ways: a formula that classifies by zone needs a template that groups by zone, or one work header carries lines from several. Microsoft's fourth example is that case: a work class per zone so "picks from a freezer zone can be restricted to workers with appropriate cold-weather gear." The formula returns a record, and reproducing only its inner call is how a reader ends up with a no-op — it is `{ WorkClassId: Concatenate("S-", workLine.ZoneId) }`, with `{ WorkPoolId: … }` as the alternative. ## Two settings reserved for future use, and an example that appears to need one Two controls are explicitly inert. **Reclassification schedule ID** — "This setting is reserved for future use and has no effect in the current release." The **Work reclassification schedules** button carries the same statement, in its own words. Now read the Important callout under Microsoft's third example, which prioritises work by minutes remaining until the shipping deadline: > "The time-remaining approach requires the reclassification batch job to run on a recurring schedule (for example, every hour) to keep priorities current." **Those two statements sit on the same page and a reader designing that example needs both.** One says the schedule setting is inert; the other says the approach requires a recurring batch job. They may refer to different mechanisms, and this article does not resolve which, because the page does not say. What it does say is which approach to prefer: the time-of-day formula "is more efficient because work only needs reclassification when the load's scheduled shipping time changes." The other reclassification control is real: **Work classification on load update** on the **Work** FastTab of **Warehouse management parameters**, values *Disabled* or *Synchronous*, with the Note that synchronous means "the user might experience a brief wait during load updates." There is also a **Preview** button, to "test a rule against an existing work header and see the results without making changes." Use it before anything reaches a picker. ## How we optimize alongside this, and where we would draw the line Pick-Path & Slotting Optimizer decides which orders travel together and which item earns which slot, writing the answer back into the wave, cluster and slotting objects Dynamics 365 executes, behind an approval step. Dynamics is the system of record; the optimization above it is a modelling problem. **A working demo exists; it is not off the shelf.** We build it against your systems and your constraints on request, and we have no delivered warehouse engagements — so this is a capability, not a report on somebody's building. Dynamic work classification is the clearest example of the boundary: it is genuinely programmable, and it still classifies work rather than deciding what the work should be. We would not put a model inside a Power Fx formula. A formula that calls a model at work creation couples your data science to your picking runtime. We would not build a customer's foundation on a Production Ready Preview name either. We design against the documented fields and let the label settle. ## What to do this week 1. **Read the feature name in feature management, not a summary.** The string beside the toggle is the status you are actually running. 2. **Check your version against the 10.0.48 floor**, and note that 10.0.49 turns the feature on by default. 3. **If you write a rule, write both formulas.** The work formula does not touch the first pick/put pair; the initial work line formula does. 4. **Check the work template's header breaks against your formula's logic.** Classify by zone and the template must group by zone. **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 someone on your team is about to write warehouse logic in Power Fx, book a fifteen-minute call and we will read the rule with you — what it can override, and where it stops. No deck. https://cognilium.ai ## Sources - [Dynamic work classification](https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/dynamic-work-classification) - [New and planned features for Dynamics 365 Supply Chain Management, 2026 release wave 1](https://learn.microsoft.com/en-us/dynamics365/release-plan/2026wave1/enterprise-resource-planning/dynamics365-supply-chain-management/planned-features) ## Sources - [learn.microsoft.com — dynamic work classification](https://learn.microsoft.com/en-us/dynamics365/supply-chain/warehousing/dynamic-work-classification) - [learn.microsoft.com — planned features](https://learn.microsoft.com/en-us/dynamics365/release-plan/2026wave1/enterprise-resource-planning/dynamics365-supply-chain-management/planned-features) --- Canonical HTML: https://cognilium.ai/blogs/power-fx-dynamic-work-classification