Architectural Overview
The OrderManagementSettings metadata type controls the core activation switches for Salesforce Order Management (SOM). In omnichannel architectures linking B2B Commerce, B2C Commerce, or third-party storefronts to Salesforce, SOM serves as the central hub for order capture, inventory reservation, fulfillment routing, and payment settlement.
Deploying OrderManagementSettings activates the immutable order ledger schema—including OrderSummary, OrderItemSummary, FulfillmentOrder, PaymentAuthorization, and ReturnOrder. Without this metadata type configured in your source control repository, automated CI/CD builds deploying SOM flows, CustomObject extensions, or ApexClass triggers fail immediately due to missing schema objects.
Directory and File Conventions
In SFDX source format, OrderManagementSettings is represented as an XML file under the settings/ directory and referenced using the Settings type with member OrderManagement.
| Property | Value |
|---|---|
| Metadata Type Name | Settings (member: OrderManagement) / OrderManagementSettings |
| SFDX Directory | force-app/main/default/settings/ |
| File Suffix | .settings-meta.xml |
| Full File Path | force-app/main/default/settings/OrderManagement.settings-meta.xml |
| Scratch Org Setting Key | orderManagementSettings |
Key Metadata Fields
The OrderManagementSettings metadata type exposes several configuration flags that determine how orders are ingested and orchestrated:
| Field Name | Field Type | Required | Architectural Description |
|---|---|---|---|
enableOrderManagement |
boolean |
No | Enables the Salesforce Order Management engine and provisions order summary standard entities. |
enableB2CIntegration |
boolean |
No | Enables native B2C Commerce (Salesforce B2C Commerce Cloud) integration pipelines and sync webhooks. |
enableHighScaleOrders |
boolean |
No | Activates high-scale ingestion, queuing peak order traffic into asynchronous ingestion buffers. |
enableOrderSummaries |
boolean |
No | Controls whether orders automatically transition into immutable OrderSummary aggregate records. |
Note
Setting enableHighScaleOrders to true alters the transactional architecture of order creation. Orders are accepted asynchronously via high-scale endpoints and staged before database commit, preventing CPU timeout bottlenecks during flash sales.
Declarative XML and Package Manifest Examples
Below is an enterprise configuration for an omnichannel order processing deployment:
<?xml version="1.0" encoding="UTF-8"?>
<OrderManagementSettings xmlns="http://soap.sforce.com/2006/04/metadata">
<enableB2CIntegration>true</enableB2CIntegration>
<enableHighScaleOrders>true</enableHighScaleOrders>
<enableOrderManagement>true</enableOrderManagement>
<enableOrderSummaries>true</enableOrderSummaries>
</OrderManagementSettings>Scratch Org Definition Configuration
When creating scratch orgs for order management development, include the feature license and settings configuration:
{
"orgName": "Omnichannel SOM Dev Org",
"edition": "Enterprise",
"features": ["OrderManagement", "B2BCommerce"],
"settings": {
"orderManagementSettings": {
"enableOrderManagement": true,
"enableB2CIntegration": true,
"enableHighScaleOrders": true,
"enableOrderSummaries": true
}
}
}Package Manifest (package.xml)
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>OrderManagement</members>
<name>Settings</name>
</types>
<version>68.0</version>
</Package>CLI Retrieval and Deployment Commands
Manage OrderManagementSettings using the Salesforce CLI (sf):
# Retrieve OrderManagementSettings from the org
sf project retrieve start --metadata Settings:OrderManagement
# Deploy OrderManagementSettings to a target environment
sf project deploy start --metadata Settings:OrderManagement
# Deploy with dry-run validation
sf project deploy validate --metadata Settings:OrderManagement --test-level RunLocalTestsArchitect Best Practices and Gotchas
- Dependency Pipeline Sequencing: Always deploy
OrderManagement.settings-meta.xmlin an initial foundational deployment step before deploying Flow definitions, ApexClass fulfillment triggers, or custom fields onOrderSummary. - Irreversibility in Production: Once Order Management is active and business transactions generate
OrderSummaryrecords, togglingenableOrderManagementoff is permanently restricted. Test all settings in full sandboxes before applying to production. - High-Scale Order Ingestion Timing: When
enableHighScaleOrdersis active, order insertion does not invoke synchronous Apex triggers onOrder. Ensure routing logic executes againstOrderSummaryCreatedEventor asynchronous platform events.
Warning
Scratch org creation will fail if "OrderManagement" is specified in features but the parent dev hub lacks the Salesforce Order Management license allocation.
Frequently asked questions
What primary capabilities are enabled by OrderManagementSettings?
It activates Salesforce Order Management, provisioning OrderSummary, FulfillmentOrder, and payment processing objects required for post-order orchestration.
Why do deployments of OrderSummary custom fields fail in scratch orgs?
OrderSummary and related fulfillment entities do not exist until enableOrderManagement is set to true in OrderManagementSettings and the org feature is active.
How do you retrieve OrderManagementSettings via the Salesforce CLI?
Execute sf project retrieve start with metadata Settings:OrderManagement to extract OrderManagement.settings-meta.xml into the local settings directory.
Can OrderManagementSettings be disabled after being activated in production?
No. Once Order Management is activated and OrderSummary records are generated, disabling the setting is restricted to prevent relational data corruption.
Comments
Questions, corrections and tips are welcome. Comments are GitHub Discussions, so you sign in with GitHub.