Analytics
What to know
Analytics in Order Management focuses on reporting on order, fulfillment, and inventory performance. Candidates should understand the objects and metrics commonly reported: order volume, fulfillment cycle time, fill rate, backorders, cancellations, and returns. Know that reporting typically draws from Order, Order Summary, Fulfillment Order, and related objects, and that report types and dashboards are built on these.
Understand that analytics depends on accurate status transitions and timestamps - e.g., order activation time, fulfillment completion time - to compute cycle times. Know that historical/trend reporting may rely on summary or snapshot data, while operational reporting uses live records.
Traps
- Confusing fill rate (fulfilled vs. ordered) with on-time rate (met promised date).
- Assuming dashboards update in real time - some rely on scheduled refresh or snapshots.
- Overlooking that canceled and returned quantities must be excluded or handled separately when computing fulfillment metrics.
- Reporting on the wrong layer (Order vs. Order Summary) yields inconsistent counts.
Rule of thumb
Define the metric before choosing the object: fill rate = fulfilled qty ÷ ordered qty; cycle time = completion timestamp − start timestamp. Match the metric to the right object and timestamp.
Worked example
To compute fill rate for a period: sum fulfilled quantities across Fulfillment Order Line Items, divide by total ordered quantities on Orders created in that period, excluding canceled quantities from the denominator or reporting them separately per your definition - state the definition explicitly.
Security
What to know
Security in Order Management follows the Salesforce sharing and permission model. Candidates must understand profiles, permission sets, permission set groups, object permissions (CRUD), field-level security, record-level sharing (org-wide defaults, role hierarchy, sharing rules), and restriction rules where applicable. Know that Order Management users often need access to Order, Fulfillment Order, Inventory, and Payment objects, and that least-privilege design matters.
Understand that Apex sharing and manual sharing can extend access, and that guest user access for commerce integrations must be tightly scoped. Know the difference between object-level and field-level access, and that a user needs both to view a field.
Traps
- Assuming object permission alone grants field access - field-level security still applies.
- Forgetting that record access is separate from object/field permissions.
- Over-permissioning integration or guest users.
- Confusing profiles (one per user) with permission sets (multiple per user).
Rule of thumb
Access requires three gates: object permission (can I see the object?), field-level security (can I see the field?), and record access (can I see this record?). All three must pass.
Worked example
A fulfillment clerk can view the Fulfillment Order object and the Status field, but a sharing rule restricts records to their region. They see only fulfillment orders in their region, and only the fields granted by FLS - even though object permission is broad.
Troubleshooting
What to know
Troubleshooting in Order Management requires tracing a problem across the data model and integrations. Common issues include orders not activating, fulfillment orders not created, routing failures, inventory mismatches, payment capture failures, and integration errors. Candidates should know where to look: order and fulfillment order statuses, orchestration logs/flow errors, integration error records, and payment authorization/capture records.
Understand that many failures are configuration issues (missing routing rules, inactive locations, missing inventory) or data issues (bad external IDs, invalid quantities). Know that platform events and flow errors are key diagnostic surfaces, and that re-running orchestration after fixing data is a common remedy.
Traps
- Jumping to code fixes when the cause is configuration (routing, location, inventory).
- Assuming a failed payment is a gateway outage when it may be an authorization that expired.
- Ignoring integration error records that pinpoint the failing field.
- Forgetting that an inactive location or missing product inventory blocks fulfillment order creation.
Rule of thumb
Troubleshoot in order: data → configuration → integration → code. Check the record statuses and error logs first, then routing/location/inventory settings, then integration errors, and only then custom logic.
Worked example
An order activates but no fulfillment order appears. Check: is there a fulfillment plan? Do routing rules match the item? Is the target location active and does it have available inventory? Often the location lacks available stock, so routing finds no source - fix by adding inventory or a fallback rule, then re-run orchestration.