OM and DRO Order Fulfillment Flow

Each engine (CME MP or RC) fulfills end-to-end within its own pipeline, but cross-engine account contamination can cause failures, making separate accounts and strict submit-path discipline essential.

Required Editions

Available in: Classic and Lightning Experience
Available in: Enterprise, Unlimited, and Developer Edition

Findings

  • End-to-end fulfillment works within the respective scope (CME MP and RC). The full flow of create, submit, orchestrate, and assetize completes for CME MP orders through OM and for RC orders through DRO in the same shared org.
    Note
    Note

    Submitting a CME MP order fails when the target account already has RC assets created first.The reverse works even if it's repeated that submitting an RC order to an account that already has CME MP assets succeeds, and a subsequent CME MP order to the same account also succeeds.

    The recommendation is to use separate accounts between CME MP and RC. A business fulfilling through both OM and DRO should maintain two accounts, one for the CME MP pipeline and one for the RC pipeline. This is especially recommended if you’ll have RC assets created before CME MP assets on an account

Guidelines

  • Treat OM/OM+ and DRO as two parallel pipelines that never share configuration they meet only at the standard Order object.
  • Every order must be classifiable to one engine (CME MP or RC) at creation; only the owning engine (CME MP or RC) should act on it.
  • Assetization is the end-state proof point for either engine.

Best Practices

  • Submit the CME MP orders only through the CME MP native submit path. Submit RC orders only through the standard RC submit action.
  • Keep test data clean per engine (CME MP or RC). Reusing one engine's assets for the other's test runs produces misleading failures.
  • Validate the full pipeline with a non-admin user for CME MP or RC respectively.

Solutions

  • Use separate accounts between CME MP and RC, especially if you’ll have RC assets created before CME MP assets on an account.

Limitations

  • Isolation of orders is custom implementation based. Neither OM nor DRO performs an origin check on incoming orders.
  • A CME MP order can be incorrectly submitted to DRO by changing the interface implementation.
  • For CME MP the batch jobs and triggers may fetch RC orders but don’t update RC specific fields. They may update CME MP specific fields on RC records, which have no meaning in the RC context.
  • Submitting a CME MP order to an account that had RC assets created first, fails.