---
schema_version: "1"
id: 6bcc1ad809dcaae95f1e063a49d0941af301b68db41d594d437cfcfebaf32cd2
title: OM and DRO Fulfillment Design
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/ind/264-0-0/comms_om_and_dro_fulfillment_design.md
canonical_url: https://help.salesforce.com/s/articleView?id=ind.comms_om_and_dro_fulfillment_design.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: ce6dc296cf36f9795979bb51d37bb1947284e756db30f4bcfb47557b308f605f
description: OM/OM+ and DRO use fully separate, non-colliding objects. However, the platform doesn’t prevent a single product from being wired into both engines, making strict app-scoped design and record type differentiators essential.
products:
  - Communications
  - Media
  - Energy and Utilities
release: "264"
---
# OM and DRO Fulfillment Design

OM/OM+ and DRO use fully separate, non-colliding objects. However, the platform doesn’t prevent a single product from being wired into both engines, making strict app-scoped design and record type differentiators essential.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: Classic and Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>Enterprise</strong>, <strong>Unlimited</strong>, and <strong>Developer</strong> Edition</td></tr></tbody></table>

## Findings

- Both engines model the same seven core concepts with different objects and granularity. The Scenario linkage for DRO (RC) is ProductFulfillmentScenario and for OM (CME MP) it’s OrchestrationScenario\_\_c. Similarly, the Decomposition rules for DRO (RC) are DRO decomposition rules and for OM it’s DecompositionRelationship\_\_c.
- The design surfaces are cleanly separate. DROs Fulfillment Workspace (RC) and OM's fulfillment diagram (CME MP) don’t interfere. Fulfillment and decomposition rules are fully independent, with no schema collision.
- Neither engine reads the other's design tables at runtime.
- The platform doesn’t prevent a single product from being wired into both engines. For example, the DRO decomposition rule destination picker shows products from both apps, so you could errorneously create decomposition rules for an EPC product that reference RC products. Decomposition rules must not cross application boundaries.

## Guidelines

- Treat OM or OM+ and DRO as two parallel orchestration engines with no shared configuration objects; they meet only at the standard Order or OrderItem layer.
- A single product must wire into both apps (CME MP or RC) decomposition and fulfillment artifacts. EPC products for OM/OM+ only; PCM products for DRO only.
- Platform events differ, author downstream subscribers per engine.

## Best Practices

- App-scoped design surfaces in DRO it’s the Fulfillment Workspace, RC, or PCM apps. For OM its XOM app, Product Designer or Pricing Designer.
- In decomposition rules, the source and destination product must always belong to the same app (CME MP or RC). Never mix products across apps.
- One scenario link per product, per engine.
- Route each engine's steps to its own queues; keep try again policies and external-system definitions per engine.
- Any custom filter on dashboard or report to distinguish OM orders from DRO orders.
- Use a naming convention to avoid product confusion across apps (optional aid).

## Solutions

- Assign the custom LWC product listing pages to the related DRO and OM apps.
- To prevent a single product record from being wired into both engines (CME MP and RC). Use a runtime RecordType.DeveloperName differentiator check in flows, triggers, and subscribers, combined with record-type-filtered product listings and naming discipline. This limits downstream damage but doesn’t prevent a design-time mis-wire.

## Limitations

- The platform provides no automatic design-time guard against wiring one product into both engines, or against selecting a wrong-app destination product in a decomposition rule — design carefully.
- Fallout or error handling can’t be unified — the two engines' error models differ, so a customer running both operates two error-handling surfaces.
- CME MP - DRO Interop is supported in a CME MP-only org. In a co-existence org (CME MP and Revenue Cloud together), CME MP - DRO Interop is not supported.