Optimal approaches and considerations

When multiple change requests update the same attribute, the order in which they are added to the release vehicle determines the outcome. For example, an update action change request (OpsU1) changes the color attribute of Credit Card from Blue to Black, while OpsU2 changes it back from Black to Blue. If OpsU1 is added first, and OpsU2 is added last, the final color becomes Blue; if the order is reversed, the final color becomes Black. In short, the last change request in the sequence always takes precedence in the generated artifacts.

Change requests are components within a Release Vehicle. If a change request requires modifications after the Release Vehicle enters the Generate stage, you must first return the Release Vehicle to the Plan stage before reopening and updating the change request.

Even when working with rules that fully support concurrent changes, coordinate with other teams when modifying the same field of the same artifact. When two teams edit identical fields, there is a chance for overwriting and data loss. Even though the system handles this, Proactive coordination prevents unintended overwrites and ensures that all team changes are preserved in the final deployment.

As a best practice, for business rules that support partial concurrency, prefer additive modifications. For example, when working with When rules and similar artifacts, add a new rule rather than amending an existing one. This approach minimizes potential conflicts and preserves existing functionality.

When multiple change requests create or modify SMS treatments and pack in the same Release Vehicle, the system stores the rules in dedicated branches that can contain overlapping SMS Treatment Decision data records (DDRs). If you include these in the same Release Vehicle, the last-merged branch can overwrite earlier changes, potentially causing data loss.

As an optimal approach, avoid using internal SMS treatments that you created using Other Type change requests during the Create Action lifecycle. Instead, you can create new SMS treatments within the workflow. Similarly, avoid creating new internal SMS treatments in the Update Action lifecycle, create an SMS treatment using other type change request and use that while updating an action. This prevents conflicts and ensures data integrity across your SMS treatment configurations.

Note that you cannot preview undeployed treatments until deployment is completed, even though you can reuse such treatments across actions. Internal SMS treatments created under Other Type change requests become available for editing only after deployment.

Other Type change requests make changes directly in the Customer Decision Hub portal. Unlike Operations Manager change request, these do not use just-in-time rule generation. Instead, rules generate after the build stage completes.

Return to Plan (RTP) and Return to Build (RTB) actions are not supported for manual tasks. For example, if a When rule is created using an Other Type CR and the Build stage is complete, the When rule becomes part of the OpsCR-<ID>_MT branch. Even if the user clicks Return to build, the When rule remains in the same branch. Users cannot add multiple tasks within an Other Type change request.

Consider this scenario: U+ Bank have three release vehicles - RV1 (Summer Release), RV2 (Emergency Fixes), and RV3 (Autumn Special)/. They want to test multiple release vehicles together in higher environments, you can create multiple CDH applications and within the Testing Cloud environment and corresponding business change test pipelines. In this scenario, the bank creates two applications: UAT Alpha and UAT Beta.

Testers validating Emergency Fixes would use the UAT Alpha application, while testers validating the Summer Release would use the UAT Beta application. This approach allows parallel testing of multiple release vehicles without conflict. You can have only one Release Vehicle at a time in an application.