Dynamics 365 Store Commerce Contextual Switching: Deep Links for External POS Apps

Entered into public preview in April 2026 and reaching general availability in June 2026 for Worldwide standard multi-tenant cloud instances, this update allows external applications and the Store Commerce point of sale (POS) to pass live transaction, customer, and product context back and forth through custom protocol URLs and web parameters. While Microsoft’s release documentation highlights that no new switches need to be flipped in Commerce headquarters, enterprise IT teams should read the fine print carefully: this is a developer-grade extensibility plumbing upgrade, not a plug-and-play widget for store managers.

Why the Retail Counter Needed a Better Handshake​

In complex retail and business-to-business (B2B) sales environments, the point-of-sale terminal is rarely the only application on the desktop. Since Microsoft deprecated legacy Modern POS (MPOS) and Retail hybrid apps in October 2023 in favor of the modern Store Commerce app for Windows, mobile platforms, and web browsers, organizations have increasingly consolidated their checkout workflows onto Store Commerce. However, specialty retailers still depend heavily on outside software—such as proprietary automotive fitment databases, third-party warranty portals, clienteling tools, or custom B2B catalogs.

Historically, bridging the gap between those third-party tools and Dynamics 365 POS meant choosing between two unappealing options: paying for expensive, tightly coupled custom integrations inside the POS shell, or forcing store associates to manually re-key product numbers and customer IDs across windows. Manual re-entry slows down the checkout line and introduces human error at the exact moment a customer is ready to pay.

Contextual switching addresses this by formalizing a two-way workflow between Store Commerce and external tools:

• Outbound (POS to External App): A sales associate working inside Store Commerce triggers the standard Open URL POS operation to launch an external tool, such as a specialized parts-lookup utility.
• Inbound (External App back to POS): Once the associate selects the required parts or completes the external task, the outside application calls Store Commerce back via a deep-link URL loaded with contextual parameters—such as a customer ID, product variant IDs, and item quantities.
• Automated Navigation and Execution: Store Commerce catches the incoming request, decodes the payload, and automatically navigates to the appropriate screen with the items or order details already loaded.

Microsoft Learn documentation outlines three primary real-world scenarios where this architecture shines: looking up items in an external proprietary catalog and adding them directly to an active Store Commerce transaction; launching a clienteling session from an appointment notification with a customer's profile and wishlist items preloaded; and handing off an approved back-office order via a link that immediately recalls the order at the register for fulfillment.

Under the Hood: How the Deep-Link Protocol Works​

According to Microsoft Learn’s developer documentation for Store Commerce, the mechanism driving contextual switching relies on custom protocol URLs for the installed Store Commerce app and query parameters for browser-based Cloud POS (CPOS) deployments.

The URL structure is divided into strict components:

1. ms-d365sc://: The custom protocol scheme registered on the client OS by the Store Commerce application.
2. executeAction: A fixed path that tells the application to run a specific business operation.
3. actionName: A plain-text, unencoded identifier for the target action (kept readable specifically to aid IT logging and diagnostics), such as D365.CreateTransaction.
4. param: A UTF-8 JSON object containing the action parameters, serialized and encoded in standard Base64.

For example, if an external parts catalog wants to void an existing draft and spin up a fresh transaction for customer 004003 with two specific product variant RecordId values, the external app constructs a JSON payload specifying "customerId", an "items" array with "productId" and "quantity", and a "mode" of "VoidAndCreate", encodes that string into Base64, and fires the protocol URL.

From a systems engineering perspective, there is an important guardrail to keep in mind: Microsoft explicitly warns developers to keep the total constructed URL length under 2,048 characters. If your external B2B catalog attempts to pass a massive shopping cart with dozens of line items in a single Base64 query string, you risk hitting URL truncation limits.

Prerequisites, Platform Support, and Queue Behavior​

Before Windows administrators and retail developers start wiring up external apps, they need to verify their environment against Microsoft's technical prerequisites:

• Minimum App Version: Store Commerce version 10.0.48 or later is required.
• SDK Version: Developers building custom extensions should use the latest Commerce SDK, such as version 9.58 or higher.
• Feature Flag: The StoreCommerce.EnableDeepLinkFlight feature flag must be active (Microsoft notes this is enabled by default in supported releases).
• OS and Platform Boundaries: Contextual switching via custom protocol URLs is currently supported on Windows, Android, and Cloud POS. Support for iOS is listed as planned but is not yet available.

How the application behaves when called depends on whether Store Commerce is already running on the associate's terminal:

• Warm Start (App Running): If the associate is already signed in and Store Commerce is open in the background, the running instance intercepts the URL and executes the requested action immediately.
• Cold Start (App Closed) or Unauthenticated: No action can execute without an authenticated user. If Store Commerce is closed, or if the associate is sitting at the login screen when the URL is triggered, the application launches and queues the incoming request until sign-in is completed.

IT architects should pay special attention to how that queue operates. Store Commerce only holds one queued request at a time. If an impatient user clicks three different callback links in an external app before signing into the register, only the final click survives—each new request overwrites the previously queued item. Furthermore, any queued request is wiped clean when a user signs out.

Extensibility: Custom Actions, Replacements, and Triggers​

While Microsoft provides built-in actions prefixed with D365. (whose exact parameter contracts are defined in the POS extensibility API under PosApi/Extend/DeepLink and the Commerce.Framework.DeepLink namespace, such as ICreateTransactionActionParameters, ICreateCustomerOrderActionParameters, and IRecallOrderActionParameters), enterprises aren't restricted to out-of-the-box behaviors.

If a retailer needs custom context handling, developers can use three supported extension patterns registered inside manifest.json:

1. Create a Custom Action: By extending DeepLinkActionHandlerBase from PosApi/Create/DeepLink, developers or Independent Software Vendors (ISVs) can build entirely new workflows. To prevent naming collisions between different vendors, the framework automatically prefixes custom action names with the extension package name (for instance, ContosoRetail.CheckInventory).
2. Replace a Built-In Action: Developers can completely override standard D365.* actions by extending the corresponding replacement handler class (such as CreateTransactionReplacementDeepLinkActionHandler). Note that this is a total replacement—your custom code does not retain access to Microsoft's underlying default implementation.
3. Hook Into Triggers: If you just need to validate incoming data, log activity, or run post-processing without rewriting the action itself, Store Commerce provides three global triggers: PreDeepLinkAction (which is cancelable and runs prior to execution), PostDeepLinkAction (which runs after success), and DeepLinkActionFailure (which catches errors).

Practical Takeaways for Enterprise IT​

Microsoft's roadmap summary notes that "no additional configuration is required in Commerce headquarters or POS". While technically true from a cloud toggle standpoint, IT leaders should not mistake this for a zero-effort deployment. Making contextual switching work in the real world requires software engineering on the external application to format and fire the ms-d365sc:// or CPOS URLs, alongside optional TypeScript/POS API development if custom action handling or validation triggers are desired.

For retail IT teams running Store Commerce on Windows 10 or Windows 11 terminals, this capability offers a clean, supported alternative to brittle UI automation or heavy back-end middleware. By keeping the integration at the protocol layer and enforcing authentication before any action fires, Microsoft has given developers a practical way to link legacy or specialized line-of-business apps directly into the modern checkout flow. Just remember to check your Store Commerce build numbers, keep your Base64 payloads under the 2,048-character ceiling, and remind your store associates that signing in first makes the magic happen a whole lot faster.