This section covers the Apex triggers, Flow processes, and Platform Event subscribers.
Required Editions
| Available in: Classic and Lightning Experience |
| Available in: Enterprise, Unlimited, and Developer Edition |
Findings
- CME MP triggers fire in every context, including for a user with no CME MP license, and can’t be turn off per user or per app. Under a Revenue Cloud–only user, these triggers can still run and may reference fields outside that user’s access. No functional impact is expected, but because behavior can vary with your org’s configuration, validate this in your environment.
- CME MP side batch jobs and triggers may fetch RC records 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.
- CME MP's XOM order trigger fires on any order change; its batch jobs are OM-only and are never run by a RC/DRO user. Some run manually; some run in the OM async pipeline. Where a job reads standard records, it updates only Order and Attachment (filtered on OM-specific fields) and reads all other standard objects without modifying them.
- Some managed package triggers create more child records for every new product regardless of app. These don’t break RC behavior but do add rows to the managed-package tables.
- Platform event subscribers can’t be application scoped, an event published by one application reaches every subscriber; subscribers must filter by source at handling time.
Guidelines
- Custom triggers, batch jobs, and automation must be origin-aware. apply the differentiator filter as the first step and skip early if the record doesn’t belong to the intended scope (CME MP and RC).
- Test every trigger and flow under a CME MP only non-admin, an RC only non-admin, and a shared admin to ensure correct behavior across all user types.
Best Practices
- Declare each custom automation's owning app (CME MP or RC) in a comment or
- metadata annotation for quick identification and usage.
- Source-of-record check pattern — a custom trigger's first action buckets records into CME MP vs RC (by the marker) and dispatches only to the matching handler. This runtime record type check is the reliable cross-wiring guard (it limits impact).
- Make flow entry conditions source-aware. Don't rely on downstream decision elements.
- Handle mixed scope (CME MP and RC) payloads in bulk operations (split, then process).
- Match field-level security to the owning app (CME MP and RC); do not chain automation across apps (CME MP and RC).
Solution
- Record type + Flexipage visibility rules keep users away from records whose automation they would trip. This stops the user from getting into the situation; it doesn’t stop the automation itself, and it applies to single-record automation, not bulk operations.
Limitations
- OOTB triggers can’t be selectively disabled per app (CME MP and RC).
- Under separate users, a RC only user who touches a common entity record trips CME MP triggers, and vice versa. Under shared users, the shared user holds both licenses, so the CME MP silent error path may not fire, but cross-app triggers firing on shared records still occurs.
- Platform event subscribers can’t be app-scoped (CME MP and RC), subscribers must filter by origin at handling time.
- Single admin testing hides most of this, per-application non-admin testing is the only way to surface it.
- The source-aware discipline previous applies to custom automation only, CME MP triggers can’t be turn off or guarded per app by subscribers.