1. Summary

The standard "Automatic release of sales orders" batch job, driven by the WHSAutoReleaseToWarehouse class in the Warehouse management module, is a critical component of the order fulfillment process. This job evaluates sales orders against configurable criteria and releases qualifying orders to the warehouse for picking and shipping. The standard job is accessed via Warehouse management > Release to warehouse > Automatic release of sales orders.

This job does not support multithreading or parallel processing. It processes all warehouses sequentially within a single batch task. An organization with 20 warehouses and 4–5 batch job instances, each running 5–10 minutes per execution, is not uncommon. For an organization with hundreds warehouses, the current architecture becomes unsustainable.

Furthermore, the WHSAutoReleaseToWarehouse class contains approximately 49 methods across 13 serialization versions, with the vast majority marked as private. This prevents implementation partners from using supported extensibility patterns—Chain of Command (CoC), event subscriptions, or class extensions—to enhance or optimize the job's behavior.

We are requesting a design change (preferred) to enable native multithreading within the WHSAutoReleaseToWarehouse class, or alternatively, an extensibility enhancement to expose key private methods for partner-driven optimization.

2. Technical Analysis

A detailed technical review of the WHSAutoReleaseToWarehouse class was conducted. The findings are summarized below.

• Single-threaded execution: The class processes all warehouses sequentially within a single batch task. It does not create child batch tasks or otherwise parallelize the work across warehouses. Adding more warehouses linearly increases execution time.
• Private method restrictions: The class contains approximately 49 methods across 13 serialization versions. The vast majority of these methods are marked as private, which prevents implementation partners from using Chain of Command (CoC), event subscriptions, or other supported extensibility patterns to modify or enhance behavior.
• Complex context dependencies: Key context classes include WHSAutoReleaseToWarehouseProcessingResultContext, WHSLockedOrderHandlingContext, and WHSAutoReleaseToWarehouseSkipSOPreProcessMCRCallCenterFullReservCheckContext. These context interactions add complexity and further limit the ability to safely extend or fork the class.
• Scalability ceiling: With 400+ warehouses processed sequentially in a single thread, the job would become a critical bottleneck. Even with the current 20 warehouses, execution times of 5–10 minutes per job instance are unacceptable for business operations that require near-real-time fulfillment.

3. Request to Microsoft

3.1 Primary Request – Design Change

We request that Microsoft enhance the WHSAutoReleaseToWarehouse class to support native multithreading and parallel processing of warehouse releases. Specifically:

• The job should be capable of creating child batch tasks per warehouse (or per configurable grouping), allowing the batch framework to distribute work across available AOS instances.
• This would align the automatic release job with the pattern already established by other WMS batch processes (e.g., wave processing) that support parallel execution.
• The design should allow for configurable parallelism—for example, grouping by warehouse, by warehouse group, or by a custom attribute—to accommodate varying customer configurations.

3.2 Alternative Request – Extensibility Enhancement

If a design change is not feasible in the near term, we request that key private methods within WHSAutoReleaseToWarehouse be made extensible (protected or public, or wrapped with Chain of Command hooks). This would allow implementation partners to safely extend the class to implement multithreading and other performance optimizations without relying on fragile workarounds.

Specifically, the following methods and areas should be made extensible:

• Query construction (buildQuery or equivalent) – to allow partners to optimize or filter the query per warehouse.
• Per-warehouse processing logic – to enable parallel invocation of the release logic for individual warehouses.
• Batch task creation – to allow partners to create child batch tasks within the standard job's execution.

3.3 Business Justification

• The current architectural limitation of the WHSAutoReleaseToWarehouse class represents a scalability ceiling that will affect any D365 FSCM customer operating at enterprise scale with advanced warehouse management.
• A native solution from Microsoft would benefit the broader D365 customer base. Wholesale distribution, retail, and manufacturing customers operating large warehouse networks will all encounter this limitation at scale.
• A native design change would eliminate this risk and reduce total cost of ownership for all customers.

4. Supporting Technical Reference

The following table provides key technical reference values for the WHSAutoReleaseToWarehouse class as of application version 10.0.47 PU71:

• Class name: WHSAutoReleaseToWarehouse
• Current version (currentVersion):13
• Parameter position (lockedOrderHandling): 8
• Approximate number of methods: 49
• Serialization versions: 13
• Primary method visibility: Private
• Extensibility via CoC: Not possible for private methods
• Extensibility via event subscription: Limited to hookable methods (very few)

Verification: To confirm these values, review the WHSAutoReleaseToWarehouse class in the development environment. The currentVersion block is located at the top of the class definition. The parameter position for lockedOrderHandling can be determined by counting the parameters in the serialization contract.