Orckestra Commerce Cloud New Features

Omnichannel Order Management and Mobile Store Fulfillment (MSF)

Improved Fulfillment Options

Additional flexibility has been integrated into our new Mobile Store Fulfillment application to allow for the use of scanners in the picking phase of fulfillment and account for situations where shipments cannot be completely fulfilled by the system-selected fulfillment center.

Enhanced Scanning Support

Store associates that are picking orders can now use the new built-in barcode scanning feature to pick units of line items that are part of the order. The integrated scanning feature can now easily be enabled or disabled as required. The parameter is defined as a customer store attribute called Require Scan to pick in MSF.

When this feature is enabled, store associates that are picking orders must scan to capture product units. Administrators can always bypass scans and proceed with manual controls to pick orders. Finally, line items that are known to not be scannable can be flagged as supporting selection without scan. The property is called Allow Selection Without Scan and is configured in the Product Management application. When activated, it causes manual picking controls to be enabled for the line item in question.

Splitting shipments during order picking when expected inventory is missing

The system can now be configured to allow pickers to skip over items that were believed to be in stock but that somehow cannot be sold due to missing or broken inventory. Incomplete fulfillment can be constrained to entire line items or allow a subset of the quantity of a line item to be picked. When completing picking, items or units that were not picked are transferred to a new shipment and automatically routed to the next applicable fulfillment location. In the case of Ship From Store (SFS), the routing engine attempts to find another fulfillment location to ship the remaining items, which may be another store or distribution center. As for Buy Online Pick Up in Store (BOPIS), routing attempts to find another fulfillment location that can transfer the remaining items to the desired pickup location.

When pickers attempt to complete picking without having picked all items, they must confirm that a new shipment should be created.

Capturing item fulfillment exceptions

Store Associates can now capture item-level fulfillment exceptions. Such exceptions can be used to provide a reason for skipping a particular item during picking or provide any sort of context around an item at a given store. While it is mandatory to select an exception, the note remains optional. The list of exceptions can be configured in the Orchestrator. Exceptions can be captured or cleared at any moment while a shipment is accessible by a store in the MSF application. Exceptions can also be retrieved through the platform APIs.

Once an exception has been flagged, it is identified with a red flag.

Manifest Creation

Certain carriers such as Canada Post require the use of carrier manifests when collecting packages to ship. A carrier manifest is a single document grouping every package entrusted to a carrier for shipment for a given pickup. It is designed to accelerate pick ups by removing the need to scan every package being shipped and instead have a single scan for all packages. Manifest management and creation can now be accessed from the hamburger menu in the MSF application. From this section of the app, users can view shipments with packages to manifest, control which ones to include in a given manifest, manifest them, and print new and previous manifest documents. Packages with manifesting errors are clearly flagged, allowing users to remove them from the list of packages to manifest and to deal with exceptions with the carrier. Unmanifested packages must be scanned individually by the carrier at the time of pickup.

Once created, manifests are accessible through the Manifest History tab.

Carrier Account Filter

Shippo is one of the shipping carrier aggregators we use. Its role is to select the best possible rate among the carriers associated with a retailer. Shippo now makes it possible for retailers to define multiple carrier accounts under a single Shippo account, thus creating associations between specific store locations and carrier accounts. The objective of the feature is to allow the provisioning of specific carrier accounts for each store location to better track and manage shipping volume and costs per store, while still allowing them all to be managed under a single Shippo account. By default, a store booking shipments through Shippo considers rates from all shipping carrier accounts defined within Shippo. The new optional store configuration parameter Carrier Account List helps confine retrieved rates to a subset of the carrier accounts configured. This parameter requires a list of carrier account IDs as they are defined in Shippo.

Recovery of Shipments with an 'Unable to Route' State

When routing is unable to find a fulfillment location to fulfill a shipment, it transitions the shipment to the "Unable to Route" state. Previously, this was a terminal state preventing recovery from the OMS application used by CSR agents, similar to a shipment cancellation. The state is no longer terminal. Professional services teams can use state "Unable to route" as the starting point of a fallback fulfillment flow specific to a solution. In the next version of OCC, it will be possible for CSR agents to access and edit shipments in that state to attempt fulfillment once more.

Product Management

The Product Management application has been enhanced with catalog management features to facilitate taxonomy adjustments, as well as administration settings to control allowed maximums for parameters like attributes, variants, relationships and media items to ensure that the platform is running optimally.

Category Movements

It is now possible to move a category as well as all its subcategories to a new parent category in a single operation. When selecting the category, all its subcategories are automatically selected. The existing options can then be used to select a new destination.

Restoration of Inheritance

It is now possible to view the real state of inheritance for a given product in the product details screen and re-establish the inheritance with the parent Scope, if it has been broken, using the new Reset Overrides button.

New Administration Settings

The ability to set maximum numbers of product entities provides clients with additional control over the size and contents of their catalogs. The following settings have been added:

Maximum number of variant attributes
Maximum number of product attributes
Maximum number of media items
Maximum number of variants
Maximum number of relationships for each product

Product Import Validator

The Product Import Validator allows you to validate key items in the import files prior to going through the complete import process. This allows you to proactively identify any potential issue with the import file.

The information currently validated includes:

Schema Validation: Identifies any missing or erroneous attribute in the products. For example, if an attribute of the product is not present, the validation will fail.
JSON Schema: Validates that the JSON schema is well formed. For example, if certain system fields are missing in the files, than these errors will be highlighted.
Attribute types: Validates that the values of the attributes are consistent with the types of those attributes. For example, if a string is passed in an attribute of type number, the validation will fail.

Core Platform Improvements

Use of the Same Email Address in Multiple Dependent Scopes

OCC version 4.0 introduced the possibility for a user account email address to exist in multiple sales scopes. For example, user account abc@acme.com can exist as two different entities in sales scope A sales scope B. OCC 4.5 extends that granularity of unicity to dependent scopes. User account abc@acme.com can now exist distinctly in multiple sales or dependent scopes. Username email address scope unicity now supports global, salesScopes or dependentScope.

This is a further enhancement of a feature that allowed customers to do so in multiple sales scopes. Customers can therefore be managed independently by each scope as needed, all the while using the same email address to sign into their accounts, for their convenience. This makes it easier to manage multiple independent commerce businesses under one platform instance.

Provider Extensibility

In order to accelerate and standardize the integration process, NuGet packages have been made available to integrators wishing to tailor existing Routing, Carrier and Fulfillment providers to their specific needs.

Better Retail Commerce Model

The Better Retail Commerce Model is now available to partners. Its purpose is to provide a set of sample data to facilitate initial platform configuration and installation for developers.

Servicestack and API Browser upgrades

Our Servicestack framework has been upgraded to the latest version for improved performance and now also supports the Open API specification for API description and documentation. As part of this upgrade our API browser provides a cleaner interface and enhanced performance. You can also use the Copy to Clipboard and Download buttons to copy responses from any API endpoint.

New API Requests





POST /fulfillments/carriers/{ScopeId}/{FulfillmentCarrierId}/manifests Create manifests for a list of packages with a carrier - {CreateFulfillmentCarrierManifestRequest}


Creates or updates a fulfillment exception for a lineitem - {CreateOrUpdateFulfillmentExceptionRequest}


Deletes a fulfillment exception for a lineitem - {DeleteFulfillmentExceptionRequest}


Search for a list of fulfillment packages - {FindFulfillmentManifestPackagesRequest}




Retrieve all currencies - {GetCurrenciesRequest}




Gets statistics for products - {GetProductsStatisticsRequest}