The CME Managed Package (CME MP) and Revenue Cloud (RC) can run in the same Salesforce org, but with certain constraints and guidelines. Coexistence relies on custom implementation-based isolation. The platform doesn’t enforce a boundary between the two apps (CME MP and RC) on the shared standard objects they use. These objects include Product, Pricebook, Order, and Asset. Establishing and maintaining that boundary requires deliberate configuration.
- Overview
This guide provides insights on what to expect when CME MP and RC operate side by side in the same org independently, without interoperating. It covers design-time configuration, including setup, metadata, and data model, and run time behavior, including user flows, automation, and UI. - Prerequisites for CME MP and RC Coexistence
Establish the org-level baseline before any co-existence configuration begins. - Design Time Considerations for CME Managed Package and RC Coexistence
Design time covers all configuration tasks that an admin, product designer, pricing designer, or fulfillment designer completes before end users interact with the system. This includes designing products, pricing, promotions, catalogs, offers, fulfillment, and so on. The CME product Lightning page is assigned to CME MP apps (Product Designer, Industries CPQ, and Pricing Designer), and the RC product page to RC apps (Product Catalog Management, Price Management, RC). - Managing Admin and Batch Jobs in Coexistence Setup
Covers the admin or batch jobs available in CME MP and RC. - Run Time Behavior in CME Managed Package and RC Coexistence
Run time covers what CME MP and RC users actually see and do in the system. The boundary rule differs by operating model. Under separate users, the assigned app (CME MP or RC) is the single source of truth for what each user experiences. Permissions enforce the boundary by restricting each user to their app's surfaces. Under shared users, where a shared user carries both apps (CME MP and RC). Permissions can no longer enforce the boundary, it shifts to the record's differentiator such as record type or SourceApp__c, supported by app-scoped surfaces and validation rules. The differentiator and validation rules are the intended enforcement mechanism under a shared user; because how completely they prevent cross-app record creation depends on your configuration, validate enforcement in your environment. All run-time surfaces such as listing pages, record pages, actions, and automation, should be configured to respect this boundary. - Common Entities Access
This section covers the common entities access in general some of these might be covered in the individual sections previous. - Custom Flows, Triggers, and Automations
This section covers the Apex triggers, Flow processes, and Platform Event subscribers. - Limitations for the CME MP and RC Coexistence
Running CME MP and RC on a shared org introduces limitations around account-level assetization, managed-package triggers, and platform behaviors. Behaviors such as global search and platform events are inherently org-wide and cannot be scoped per application. Most limitations carry no functional impact today; interim guidance and workarounds are provided where available, considering the remaining items for future validation.