---
schema_version: "1"
id: 4f47a5e207f7861813dd756f8e6143d0dcf5628b8710db38bd1cdccc65766ac6
title: Managing Admin and Batch Jobs in Coexistence Setup
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/ind/264-0-0/comms_managing_admin_and_batch_jobs_in_coexistence_setup.md
canonical_url: https://help.salesforce.com/s/articleView?id=ind.comms_managing_admin_and_batch_jobs_in_coexistence_setup.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 22ef5c834be1112186bed4622dff6bfb5d90265c4a0a174358e34ebd31973e58
description: Covers the admin or batch jobs available in CME MP and RC.
products:
  - Communications
  - Media
  - Energy and Utilities
release: "264"
---
# Managing Admin and Batch Jobs in Coexistence Setup

Covers the admin or batch jobs available in CME MP and RC.

### 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

- 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.