Salesforce Order Management Administrator AP cheat sheet

Order Management uses a separate org context or the same org with Order Management permission set licenses; the OrderSummary object is the runtime order record distinct from the Order object.

FulfillmentOrder is the unit of work sent to a fulfillment location; one OrderSummary can generate multiple FulfillmentOrders split by location, delivery group, or fulfillment type.

Order Lifecycle Manager (OLM) drives state transitions via OrderLifecycleType; standard types include none, Activation, and Fulfillment, and custom types require matching OrderSummary status values.

FulfillmentOrder status values (Draft, Submitted, Allocated, Partially Allocated, Fulfilled, Canceled) are controlled by a FulfillmentOrderLifecycleType setting.

Order Summary Routing creates FulfillmentOrders using fulfillment plans and routing rules; rules can target fulfillment locations by group, priority, or custom criteria.

A Delivery Group groups OrderItemSummary records that ship together and carries ShippingAddress, DeliveryMethod, and DeliveryGroupType values.

Change orders (OrderChangeType) capture post-submission edits such as quantity decrease, cancel, or return; each change creates OrderItemSummaryChange records.

Fulfillment plan and routing configuration is stored in FulfillmentPlan and FulfillmentPlanRule; a plan is selected by routing criteria and can be overridden by order attributes.

OrderSummary statuses flow Draft → Activated → In Progress → Completed/Canceled; Activated is set when the order is submitted and fulfillment begins.

FulfillmentOrder progression: Draft → Submitted → Allocated → Fulfilled; a partial allocation yields Partially Allocated until remaining quantity is allocated or canceled.

FulfillmentOrderLineItem records hold OrderedQuantity, AllocatedQuantity, and FulfilledQuantity; fulfilled quantity cannot exceed allocated quantity.

Shipment records tie to FulfillmentOrder via FulfillmentOrderId; a Shipment can contain ShipmentItem records that reference FulfillmentOrderLineItem.

Cancellation after allocation creates a reversal: FulfillmentOrder status returns to Canceled and OrderItemSummaryChange records track the reduced quantity.

Return orders use ReturnOrder and ReturnOrderLineItem; a return can be created from a FulfillmentOrder or OrderSummary and references the original OrderItemSummary.

OrderItemSummary statuses mirror fulfillment state (Ordered, Allocated, Shipped, Fulfilled, Returned) and are updated by OLM as downstream records change.

A FulfillmentOrder in Draft can be deleted; once Submitted it must be canceled rather than deleted to preserve audit history.

Inventory is tracked at the LocationProductInventory level; AvailableToFulfill = QuantityOnHand − QuantityReserved − SafetyStock (subject to inventory policy).

LocationGroup and LocationGroupAssignment associate fulfillment locations with inventory pools for routing decisions.

Inventory reservations are created when a FulfillmentOrder is allocated; reserved quantity reduces AvailableToFulfill but not QuantityOnHand.

Inventory policies (InventoryPolicy) define whether overselling is allowed and how availability is calculated; the default policy blocks oversell.

ProductInventory records hold QuantityOnHand and QuantityReserved per Product and Location; inventory adjustments post via InventoryAdjustment or the Inventory API.

Order Management can consume inventory from an external system via the Inventory API; when external inventory is authoritative, local ProductInventory is read-only.

Backorder and pre-order behavior is controlled by InventoryPolicy and product availability; a FulfillmentOrder can be Submitted without allocation and remain unallocated.

Allocation is idempotent per FulfillmentOrderLineItem; re-running allocation does not double-reserve quantity for the same line item.

Payment records in Order Management use PaymentMethod, PaymentGroup, and PaymentAuthorization; an authorization must be captured to create a Payment.

OrderSummary carries TotalAmount, TotalTaxAmount, and GrandTotalAmount; these are calculated from OrderItemSummary and summarized at order level.

PaymentGateway records configure the external payment provider; the Payment API and PaymentGatewayProvider handle authorization and capture calls.

Billing uses Invoice and InvoiceLine records generated from FulfillmentOrder or OrderSummary; invoice statuses include Draft, Posted, and Canceled.

A refund is represented by a Payment with Type Refund or a negative amount tied to the original Payment; refunds reference the original PaymentAuthorization.

Tax is calculated per OrderItemSummary and stored in TaxAmount; tax recalculation occurs on change orders and returns.

Payment authorization expiry requires re-authorization; the PaymentAuthorization status values include Pending, Authorized, Captured, and Voided.

Billing schedules and invoice batches are configured via BillingPolicy and InvoiceBatch; billing can be triggered on order activation or fulfillment completion.

Core object chain: Order → OrderSummary → OrderItemSummary → FulfillmentOrder → FulfillmentOrderLineItem → Shipment → ShipmentItem.

OrderSummary is the source of truth post-activation; Order and OrderItem are the pre-activation records and should not be modified after activation.

Order Management Connect and the Order Management APIs (Order, FulfillmentOrder, Inventory, Payment) expose REST endpoints for external systems.

Platform Events (e.g., OrderSummaryEvent, FulfillmentOrderEvent) publish lifecycle changes for asynchronous integration; subscribers use CometD or Pub/Sub API.

External systems integrate via Connected App and OAuth; the integration user needs Order Management permission sets and API access.

Composite API and Bulk API 2.0 are used for high-volume order ingestion; the Order Management API is preferred for individual lifecycle operations.

Change Data Capture (CDC) on OrderSummary and FulfillmentOrder provides near-real-time replication of record changes to external systems.

OrderItemSummary links back to OrderItem via OriginalOrderItemId; this mapping is required for reconciliation between pre- and post-activation records.

Order Management reporting uses standard objects OrderSummary, FulfillmentOrder, and Shipment; reports must use these rather than Order/OrderItem for post-activation metrics.

Fulfillment performance metrics derive from FulfillmentOrder CreatedDate to Shipment CreatedDate (fulfillment cycle time).

OrderSummary status counts (Activated, In Progress, Completed) are the basis for open-order dashboards; filter by Status and OrderLifecycleType.

Inventory availability dashboards join ProductInventory with LocationGroup; AvailableToFulfill is the reporting metric, not QuantityOnHand alone.

Returns analytics use ReturnOrder and ReturnOrderLineItem; return rate = returned quantity ÷ fulfilled quantity over the period.

CRM Analytics (Tableau CRM) can ingest Order Management objects via data sync; standard Order Management datasets are not prebuilt and require custom recipes.

Report on OrderItemSummary for line-level revenue; GrandTotalAmount at OrderSummary level double-counts if summed across line items.

Payment reconciliation reports join Payment to OrderSummary via PaymentGroup; captured vs. authorized amounts reveal settlement gaps.

Order Management requires the Order Management permission set licenses; users need the Order Management User permission set plus object-level permissions.

Sharing for OrderSummary and FulfillmentOrder uses organization-wide defaults plus sharing rules; these objects do not support manual sharing in all editions.

Field-level security on FulfillmentOrder and Payment fields restricts sensitive data such as payment amounts and shipping addresses.

Integration users should use a dedicated Connected App with scoped OAuth and least-privilege permission sets, not admin credentials.

Apex in Order Management runs in system mode unless 'with sharing' is declared; OLM extension classes must respect sharing for data exposure.

Restricted access to Payment and PaymentAuthorization objects via permission sets limits PCI-adjacent data to billing roles.

Guest and community users cannot access Order Management objects by default; explicit sharing and permission sets are required.

Audit order changes via Field History Tracking on OrderSummary and FulfillmentOrder; enable history on status and quantity fields for compliance.

FulfillmentOrder stuck in Draft: verify a fulfillment plan matches routing criteria and the target location is active and in a LocationGroup.

Allocation fails: check AvailableToFulfill at the location; insufficient inventory or a restrictive InventoryPolicy blocks allocation.

OrderSummary not activating: confirm OrderLifecycleType is set and required fields (Account, DeliveryGroup) are populated; OLM errors appear in debug logs.

OLM errors surface in Apex debug logs with the OrderLifecycleManager namespace; enable debug logs for the integration user.

Shipment creation fails when FulfillmentOrder status is not Allocated or Partially Allocated; fulfill quantity cannot exceed allocated quantity.

Duplicate FulfillmentOrders indicate overlapping routing rules; review FulfillmentPlanRule priority and criteria for conflicts.

Payment capture failures trace to PaymentGateway configuration or expired PaymentAuthorization; check gateway logs and authorization status.

Inventory mismatch between external and local records occurs when the Inventory API sync fails; verify the Connected App and API user permissions.