The Warehouse Mobile Device Menu in D365 Advanced WMS: Menu Items and Work Classes
In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Management. Menu items, work classes, and how to design handheld flows that the floor will actually use without fighting the device. Every piece of physical movement I have written about in this series, picking, replenishment, cycle counting, receiving, put-away, reaches the operator through one screen: the mobile device menu. You can have immaculate work templates and location directives behind the scenes, but if the menu the picker sees is a deep, confusing tree of half-relevant options, the floor will be slow, error-prone, and quietly inventing workarounds. The menu is where all that back-end design either becomes usable or gets in the way.
WHAT THE MOBILE DEVICE MENU ACTUALLY IS
The warehouse mobile device menu is the tree of options an operator navigates on the handheld, from the top-level menu down through submenus to the individual actions they tap to do a job. Each leaf in that tree is a mobile device menu item, and each menu item is a small piece of configuration that decides exactly what happens when the operator selects it. Menus can contain other menus, so you can group actions by function and keep any single screen short. The whole structure is assigned to operators through their work user setup, which means different roles can see completely different menus: a receiver does not need to scroll past picking and packing options, and a picker should not be one mis-tap away from a counting flow. Designing the menu well is mostly about two questions: what is each menu item, and how is the tree arranged.
TWO MODES: WORK AND INDIRECT
The single most important setting on a menu item is its mode, and there are two. A work-mode menu item drives warehouse work: it either processes work that already exists (an operator picks up directed picking or put-away work) or it creates work as the operator acts (receiving a purchase order line generates the put-away work). Work-mode items are the ones wired to the work templates and location directives I covered in the two tables that run your warehouse; the menu item is simply the doorway through which that work reaches the floor.
An indirect-mode menu item is for everything that is not warehouse work: an item or location inquiry, a pause or break, a cleaning task, switching the active user. These do not create or process work; instead each maps to an indirect activity code, which is what lets you measure how much of the shift was spent off productive work. Getting the mode right is the first decision, because almost everything else about the item follows from it. The mistake I see most often is people reaching for complex configuration when the real problem is simply that an action was modelled as the wrong mode.
WORK CLASSES: THE GUARD RAIL ON WORK ITEMS
For a work-mode item, the work class is the setting that keeps it pointed at the right job. A work class controls which work order types a menu item is allowed to process, and which location types are valid for the work it handles. In plain terms, it is the guard rail that stops a menu item built for sales order picking from also trying to process, say, replenishment or counting work, and stops an operator from completing a step in a location type that should never hold that work. You attach work classes to the menu item, and the system will only surface and allow work that matches. Indirect items need no work class at all, because there is no work to constrain. Spending a little time on work classes pays off directly in fewer wrong moves: operators are gently fenced into the work and locations that make sense for the flow they picked.
DESIGNING THE MENU TREE
Once the items exist, the arrangement is what the floor experiences. The principles are simple and they all pull in the same direction: toward speed and away from mistakes. Group items by job, so inbound actions sit together, outbound actions sit together, inventory actions sit together, and inquiries sit in their own corner. Keep the tree shallow, because every extra level is another tap and another chance to take a wrong turn; a picker should reach their picking flow in one or two taps, not five. Give each role only the menus it needs, so the screen is never cluttered with actions that operator will never run. Name items in the language of the floor, not the language of the configuration table, so "Receive and put away" beats a cryptic internal code. And order the items within a menu by frequency, putting the action someone runs fifty times a shift at the top.
KEEP THE FLOW SHORT
Inside a work-mode item there is also the flow itself: the sequence of prompts the operator answers. The discipline here is the same one that runs through this whole series, only create the work and ask the questions that earn their keep. Prompt the operator for exactly what the system cannot infer, the item or the license plate, the quantity when it is genuinely variable, and nothing more. Every prompt the system could have answered itself is a step that slows the shift and adds a chance to key something wrong. A flow that confirms what it already knows trains operators to tap through without reading, which is how real errors slip in. Short, honest flows keep both speed and accuracy high.
WHAT GOES WRONG
• Wrong mode. An activity modelled as work when it should be indirect, or the reverse, leads to confusing behaviour and broken labour reporting. Decide work or indirect first.
• Missing or loose work classes. Without the right work class, a menu item processes work it never should, and operators complete steps in the wrong location types. Tighten the class to the flow.
• A deep, shared menu for everyone. One giant menu for all roles forces every operator to wade past actions they never use, slowing them and inviting mis-taps. Build role-based menus.
• Configuration-speak labels. Menu items named after internal codes leave operators guessing. Name them for the job in floor language.
• Over-prompting flows. Asking for fields the system already knows trains operators to tap blindly and multiplies keying errors. Prompt only for what cannot be inferred.
• Ignoring item order. Burying the most frequent action below rarely used ones taxes the floor all day. Order by frequency.
TAKEAWAYS
The warehouse mobile device menu is where all the back-end configuration meets the operator, so it deserves as much care as the work templates and directives behind it. Start with the mode of each item: work for anything that drives or processes warehouse work, indirect for the inquiries, pauses, and other non-work activities you still want to measure. For work items, use work classes as the guard rail that keeps each item on the right work order types and the right location types. Then arrange the tree for the floor: grouped by job, shallow, role-based, labelled in plain language, and ordered by how often each action is run. Keep the flows themselves short, prompting only for what cannot be inferred. Do this and the warehouse you have read about across this series finally feels fast in the hand, because the screen stops fighting the person holding it.
Next time I will step away from the warehouse and into planning: master planning in D365, starting with coverage groups and the core planning parameters that decide what the system suggests you make and buy, and when.
In this series: previous article Inbound Flows in D365 Advanced WMS: Receiving and Put-Away Directives
In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Management. Menu items, work classes, and how to design handheld flows that the floor will actually use without fighting the device. Every piece of physical movement I have written about in this series, picking, replenishment, cycle counting, receiving, put-away, reaches the operator through one screen: the mobile device menu. You can have immaculate work templates and location directives behind the scenes, but if the menu the picker sees is a deep, confusing tree of half-relevant options, the floor will be slow, error-prone, and quietly inventing workarounds. The menu is where all that back-end design either becomes usable or gets in the way.
WHAT THE MOBILE DEVICE MENU ACTUALLY IS
The warehouse mobile device menu is the tree of options an operator navigates on the handheld, from the top-level menu down through submenus to the individual actions they tap to do a job. Each leaf in that tree is a mobile device menu item, and each menu item is a small piece of configuration that decides exactly what happens when the operator selects it. Menus can contain other menus, so you can group actions by function and keep any single screen short. The whole structure is assigned to operators through their work user setup, which means different roles can see completely different menus: a receiver does not need to scroll past picking and packing options, and a picker should not be one mis-tap away from a counting flow. Designing the menu well is mostly about two questions: what is each menu item, and how is the tree arranged.
TWO MODES: WORK AND INDIRECT
The single most important setting on a menu item is its mode, and there are two. A work-mode menu item drives warehouse work: it either processes work that already exists (an operator picks up directed picking or put-away work) or it creates work as the operator acts (receiving a purchase order line generates the put-away work). Work-mode items are the ones wired to the work templates and location directives I covered in the two tables that run your warehouse; the menu item is simply the doorway through which that work reaches the floor.
An indirect-mode menu item is for everything that is not warehouse work: an item or location inquiry, a pause or break, a cleaning task, switching the active user. These do not create or process work; instead each maps to an indirect activity code, which is what lets you measure how much of the shift was spent off productive work. Getting the mode right is the first decision, because almost everything else about the item follows from it. The mistake I see most often is people reaching for complex configuration when the real problem is simply that an action was modelled as the wrong mode.
WORK CLASSES: THE GUARD RAIL ON WORK ITEMS
For a work-mode item, the work class is the setting that keeps it pointed at the right job. A work class controls which work order types a menu item is allowed to process, and which location types are valid for the work it handles. In plain terms, it is the guard rail that stops a menu item built for sales order picking from also trying to process, say, replenishment or counting work, and stops an operator from completing a step in a location type that should never hold that work. You attach work classes to the menu item, and the system will only surface and allow work that matches. Indirect items need no work class at all, because there is no work to constrain. Spending a little time on work classes pays off directly in fewer wrong moves: operators are gently fenced into the work and locations that make sense for the flow they picked.
DESIGNING THE MENU TREE
Once the items exist, the arrangement is what the floor experiences. The principles are simple and they all pull in the same direction: toward speed and away from mistakes. Group items by job, so inbound actions sit together, outbound actions sit together, inventory actions sit together, and inquiries sit in their own corner. Keep the tree shallow, because every extra level is another tap and another chance to take a wrong turn; a picker should reach their picking flow in one or two taps, not five. Give each role only the menus it needs, so the screen is never cluttered with actions that operator will never run. Name items in the language of the floor, not the language of the configuration table, so "Receive and put away" beats a cryptic internal code. And order the items within a menu by frequency, putting the action someone runs fifty times a shift at the top.
KEEP THE FLOW SHORT
Inside a work-mode item there is also the flow itself: the sequence of prompts the operator answers. The discipline here is the same one that runs through this whole series, only create the work and ask the questions that earn their keep. Prompt the operator for exactly what the system cannot infer, the item or the license plate, the quantity when it is genuinely variable, and nothing more. Every prompt the system could have answered itself is a step that slows the shift and adds a chance to key something wrong. A flow that confirms what it already knows trains operators to tap through without reading, which is how real errors slip in. Short, honest flows keep both speed and accuracy high.
WHAT GOES WRONG
• Wrong mode. An activity modelled as work when it should be indirect, or the reverse, leads to confusing behaviour and broken labour reporting. Decide work or indirect first.
• Missing or loose work classes. Without the right work class, a menu item processes work it never should, and operators complete steps in the wrong location types. Tighten the class to the flow.
• A deep, shared menu for everyone. One giant menu for all roles forces every operator to wade past actions they never use, slowing them and inviting mis-taps. Build role-based menus.
• Configuration-speak labels. Menu items named after internal codes leave operators guessing. Name them for the job in floor language.
• Over-prompting flows. Asking for fields the system already knows trains operators to tap blindly and multiplies keying errors. Prompt only for what cannot be inferred.
• Ignoring item order. Burying the most frequent action below rarely used ones taxes the floor all day. Order by frequency.
TAKEAWAYS
The warehouse mobile device menu is where all the back-end configuration meets the operator, so it deserves as much care as the work templates and directives behind it. Start with the mode of each item: work for anything that drives or processes warehouse work, indirect for the inquiries, pauses, and other non-work activities you still want to measure. For work items, use work classes as the guard rail that keeps each item on the right work order types and the right location types. Then arrange the tree for the floor: grouped by job, shallow, role-based, labelled in plain language, and ordered by how often each action is run. Keep the flows themselves short, prompting only for what cannot be inferred. Do this and the warehouse you have read about across this series finally feels fast in the hand, because the screen stops fighting the person holding it.
Next time I will step away from the warehouse and into planning: master planning in D365, starting with coverage groups and the core planning parameters that decide what the system suggests you make and buy, and when.
In this series: previous article Inbound Flows in D365 Advanced WMS: Receiving and Put-Away Directives
No replies yet. Be the first to respond!
