Click-and-collect fulfilment in Dynamics 365 Commerce
By Emil Björk · Microsoft business apps consultant, Gothenburg
How buy-online-pick-up-in-store works end to end in Dynamics 365 Commerce — delivery modes, order sourcing, store-side fulfilment in the Store Commerce app, payment capture at pickup, and the gaps you fill with partners.
Click-and-collect looks simple from the customer's side: buy online, pick up in a store. Behind it sit five systems that have to agree — the storefront, order sourcing, the store's inventory, the store's staff workflow, and payments. Dynamics 365 Commerce covers all five in one product, which is the main argument for it over stitching a storefront to a separate ERP. This guide walks the flow and points at the parts that still need attention.
Delivery modes are the switch
Everything starts with modes of delivery. Commerce distinguishes a customer pickup mode from ship-to-customer modes, and the pickup mode is what tells the rest of the system that the order will be fulfilled by a store, not a warehouse. Configure it per channel: the e-commerce channel offers pickup, the pickup happens at a store channel, and the mapping between them is explicit.
Two details worth settling early:
- Which stores can be pickup locations. Not every store should. Small-format stores with no back room, franchise stores on a different legal entity, and stores with unreliable stock accuracy are common exclusions. The store locator on the storefront respects the configuration.
- Pickup time slots. Commerce's e-commerce module library supports time-slot selection for pickup, which is what enables curbside collection as a variant. Use it if the store operation actually needs to spread collections through the day; skip it if the promise is simply "ready in two hours".
Showing availability honestly
The storefront needs to know what each store has before it offers pickup there. Commerce reads store-level available-to-promise from headquarters, and for retailers on Supply Chain Management the Inventory Visibility add-in gives a low-latency view across channels that is far better than nightly snapshots.
The practical problem is not the query, it is the source. Store stock in Commerce is only as accurate as the last statement posting and the last cycle count. Retailers that launch click-and-collect on top of stores with poor count discipline discover it within a week as "ready for pickup" emails go out for items that are not on the shelf. A safety buffer per store — offer pickup only when on-hand exceeds a threshold — is standard and configurable.
Sourcing the order
When the customer chooses a store, sourcing is trivial: that store fulfils. Where it gets interesting is ship-from-store and pickup at nearest store with stock. Distributed order management (DOM) is Commerce's sourcing engine: it takes the order, applies rules (distance, stock, store capacity, cost), and assigns fulfilment locations, splitting lines across stores when necessary.
DOM is powerful and easy to over-configure. A retailer with a hundred stores and one warehouse usually needs three rules, not thirty. Start with "customer's chosen store, else nearest store with stock above buffer, else warehouse" and add complexity only when a real problem shows up in the exception queue.
Store-side fulfilment
The store sees the order in the order fulfilment operation of the Store Commerce app. The workflow is accept, pick, pack, then either ship or mark ready for pickup. Staff can print pick lists, reject lines they cannot find, and partially fulfil. Each state change updates the order in headquarters and triggers customer notifications.
Notification emails ship in the product: order confirmation, ready-for-pickup, and picked-up templates configured per channel. SMS does not — a Power Automate flow or a partner messaging connector fills that gap. If curbside is in scope, the "I'm here" message from the customer is typically a Power Pages form or a partner app, not a Commerce feature.
Store operations decisions that matter more than configuration:
- Who owns pick-and-pack in the store. Retailers that leave it to "whoever is free" get slow orders at peak hours. Assign a role per shift.
- Where held orders live physically and how long before they are cancelled and restocked. Commerce supports the cancel-and-restock; the shelf and the policy are yours.
- How partial availability is handled. Contact the customer, ship the missing line, or cancel it. Pick one and configure the store app around it.
Payments: authorise now, capture at pickup
The correct pattern is to authorise the card at checkout and capture when the customer collects, so the customer is never charged for something they did not receive. Commerce supports this: the online order carries an authorisation, and the pickup in the Store Commerce app triggers capture through the payment connector.
The trap is authorisation expiry. Card authorisations lapse after a period set by the issuer, often a week or so, and a customer who takes ten days to collect will have a failed capture. Commerce handles re-authorisation, but the behaviour depends on the payment connector — confirm with the acquirer what happens on the tenth day before launch, and set the order-cancellation window to fit.
Returns of collected orders
A click-and-collect order is a sales order in headquarters and can be returned at any store, not only the pickup store, because the transaction is visible across the estate through headquarters. Return reason codes, refund to original tender, and cross-channel return policies all apply. This is one of the underrated benefits of Commerce over a Shopify-plus-ERP setup, where cross-channel returns usually need custom work.
Business Central retailers
On Business Central with the Shopify connector, click-and-collect is really a Shopify feature: Shopify handles local pickup in its checkout, and the order arrives in BC as a sales order tagged with a pickup location. Fulfilment status flows back from Shopify POS or a partner POS app; BC is the system of record for inventory and finance but not the workflow engine. That is fine for a handful of stores and simpler promises. It stops being fine when the retailer wants DOM-style sourcing, cross-store returns, or partial pickup — at which point the conversation is about Commerce, not another connector.
What to measure
Three numbers tell you whether click-and-collect is working: time from order to ready-for-pickup, the cancellation rate caused by stock not found, and the share of orders collected within the promised window. All three are derivable from Commerce transaction data in Power BI; none of them ship as a dashboard.
Further reading
Related guides
- Endless aisle and cross-store inventory in Dynamics 365 CommerceHow Dynamics 365 Commerce supports endless-aisle selling — customer orders from the POS, cross-store inventory lookup, deposits, fulfilment from another location, and what to build versus buy for kiosks and sales-credit rules.
- Multi-store rollout patterns for Dynamics 365 CommerceHow to structure and roll out Dynamics 365 Commerce across many stores — organisation hierarchy, scale units, data distribution, register setup, and the wave plan that keeps a 200-store rollout from stalling.
- Seasonal forecasting for retail on Dynamics 365How to forecast seasonal retail demand with Dynamics 365 — Demand Planning for store-SKU seasonality, Commerce replenishment for allocation, BC's forecast extension for small retailers, and the open-to-buy and promotion-lift gaps that still live in spreadsheets or ISVs.
- Unified commerce architecture on Dynamics 365What unified commerce actually means on Dynamics 365 — one product master, one pricing engine, one order, one customer across store, web, and call centre — how Commerce delivers it, where headless and Customer Insights fit, and why BC plus Shopify is integrated commerce, not unified.
- Dynamics 365 for retailHow Dynamics 365 fits retail — Commerce for omnichannel, Business Central for SMB retailers, and the typical retail stack.
Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.