Covers the admin or batch jobs available in CME MP and RC.
Required Editions
| Available in: Classic and Lightning Experience |
| Available in: Enterprise, Unlimited, and Developer Edition |
Findings
- Administrative jobs are expected to run without conflict between CME MP and RC. Validate this with per-application, non-admin users in your org, because a single shared administrator can mask boundary behavior.
- RC admin can’t open the CME MP administration apps (CMT Admin, Product Designer, and Pricing Designer).
- RC jobs run across all pricebooks (CME MP and RC). There’s no functional impact, but processing additional pricebooks can increase job runtime.
- CME MP admin batch jobs are of three types:
- Type 1 — The starting point is a CME MP specific object, such as priceList or catalog. This doesn’t have overlapping concerns between CME MP and RC and hence it's safe.
- Type 2 — The user supplies the input records. In this case, the user has to make sure that it passes the correct record for the intended app’s job.
- Type 3 — No input is required regarding CME MP or RC jobs. The job processes all records regardless of CME MP or RC, but updates only CME MP specific fields, so there is no functional impact.
Guidelines
- Any custom job that you develop must have a clearly identified scope between CME MP and RC and must not act on the other's records.
- Schedule and monitor custom jobs separately for CME MP and RC. A failed job in one must not silently block the other.
- For jobs that require user-supplied (Type 2) input records, ensure that only the correct records are passed, either CME MP or RC.
Best Practices
- Separate admin users per app where possible, avoid running both apps' jobs under one identity. (Validate the exact behavior of per-application non-admin users in your org.)
- Schedule non-overlapping windows, CME MP, and RC batch windows should not run concurrently on shared objects; interleave them to keep root-cause analysis clean.
Solutions
- For custom batch jobs, add a marker-based filter (record type or
SourceApp__c) so the job acts only on its intended records and doesn’t overlap between CME MP and RC.
Limitations
- Administrative jobs don’t respect app boundaries automatically. Most CME MP jobs are safe because they start from a CME MP specific object. A few jobs operate on all records regardless of app. They update only CME MP specific fields so no functional impact on RC. Their queries can’t be modified by customer out-of-the-box implementations.