Salesforce Docs Portal

Prerequisites for CME MP and RC Coexistence

Establish the org-level baseline before any co-existence configuration begins.

Required Editions

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

Org and installation Both apps (CME MP and RC) can be installed on the same org. You can install CME MP first, then turn on and set up RC. Confirm the exact sequence for your target org with your Salesforce account team, and perform the install in a sandbox first.

Users and Permissions Create specific non-admin test users: one CME MP only, one RC only, and one shared admin, so both operating models are in use. Apps are assigned to a user via a profile or permission set.

Note
Note Full migration from CME MP to RC isn’t covered here. Co-existence is a structural arrangement, not a migration path. Doesn’t cover interoperability between CME MP and RC, they’re independent.

The Differentiator Model

Use the differentiator or marker pattern to segregate records between CME MP and RC. This gives end users a clear view of which records they’re accessing. Consider deciding on the differentiator before starting the usage of RC on CME MP org.

Recommended differentiator pattern: mark the new, default the incumbent. Mark only the net-new RC records explicitly. Anything unmarked is treated as CME MP. Because CME MP is the incumbent and RC is new, this avoids reclassifying any existing CME MP data.

Apply this by object capability:

  • Record type (preference) where the object supports it — Product, Order, Opportunity, and Quote.
    • CME MP keeps its standard record types unchanged; for RC create net-new record types.
  • A custom field (for example, SourceApp__c) where there’s no usable record type — Pricebook. Set it to RC at creation. A blank value means CME MP.
    • Pricebook Entry inherits its parent Pricebook — it may not carry any marker of its own.
    • Filter idiom: If the marker value is RC — treat everything that isn’t RC as CME MP (this correctly includes unmarked records). Avoid explicit filter on specific CME value.
  • Guarantee RC marking — default record type per RC profile, default field value, and a validation rule. An unmarked RC record is silently treated as CME MP. A blank marker is a legitimate CME MP state, not missing data.

Considerations

  • Isolation before integration. The two apps (CME MP and RC) are functionally separate. As much as possible, try to keep the data each uses or generates separately. Shared functions (report generation, global search) will surface data from both; handle them explicitly.
  • Mark the new, default the incumbent. When distinguishing records, mark only the RC (net-new) records explicitly. Everything unmarked is treated as CME MP. This avoids reclassifying existing CME MP data.
  • Use separate profiles and users for CME MP and RC where possible, and assign the respective apps to the correct profiles.
  • Admin user runs are smoke checks only. Where possible, try for using dedicated CME MP only and RC only non admin users.
  • Verify co-existence in a sandbox first, resolve conflicts, test, and then promote to production. Some conflicts are specific to a customer's own implementation.
  • Use only the app-specific and related apps when designing each application's (CME MP and RC) objects.
  • Run test automation simultaneously across both apps to verify co-existence scenarios.