Concurrency levels in Concurrent Change Management

Change request types that use just-in-time Rule generation support complete concurrency so that multiple teams can work on the same Rule in parallel. You can associate these types of change requests with release vehicles for coordinated testing and deployment. Generating these Rules just-in-time in release vehicle-specific Branches supports simultaneous work. Multiple teams can modify the same rule in parallel, package their changes into the same or different release vehicles, and deploy in any order. However, if two deployments change the same field, the most recent deployment takes precedence. Rule Types that use just-in-time Rule generation and support full concurrency include:

• Actions
• Action-level Engagement Policy
• Treatments
• Customer Journeys

There are certain types of change requests that you cannot complete in 1:1 Operations Manager. Instead, you create a change request from 1:1 Operations Manager, assign a manual task, and use the Customer Decision Hub Portal to make the change directly. This approach captures only a high-level description of the change in the change request and makes the detailed update directly in Pega Customer Decision Hub™. These change requests are in the Other category, which you access in the Create menu, as shown in the following figure:

These types of change requests cannot follow just-in-time Rule generation because the system generates the Rules on completion of the manual task. The system creates a dedicated Branch for these Rules. Each change request uses a dedicated manual task (MT) Branch. You can still associate these change requests with a release vehicle and then deploy them across different environments. For these types of changes, you can add new artifacts in parallel and deploy independently. However, the system does not support amending existing artifacts in parallel because of concurrency conflicts. The Rules generated in dedicated MT Branches that support partial concurrency include:

• New internal SMS treatment
• New When Rule
• Existing internal SMS treatment
• New Audience
• New Data Base or File output template
• Edit Custom decision data record

In Concurrent Change Management, Next-Best-Action Designer changes, which are part of the Other change request functionality, follow a different pattern. These types of changes generate Rules immediately after completion of the change request and reside in a single Revision Management (RM) Branch. This branch automatically deploys with the next release vehicle heading to production. You cannot delay deployment or select a specific release vehicle for these updates. The Rules generated in RM branches and having no concurrency include:

• Add or edit taxonomy
• Manage Real-time containers, Events, and outbound schedules
• Manage group-level engagement policies
• Manage Prioritization settings (Arbitration)
• Edit contact policies, Channel, and action limits

U+ Bank is launching an emergency release vehicle with two new offers and a new audience. Recently, the bank updated the engagement policy for the credit card group. This release contains three Branches to deploy:

• Release vehicle (RV) Branch: Carries two new offers
• MT Branch: Carries audience and segment
• RM Branch: Carries the engagement policy change

This balanced approach addresses different business needs. The flexibility of Concurrent Change Management supports careful coordination when multiple teams want to synchronize their work in parallel.