Pega Rule Override: How Retrofitting Prevents Lost Changes in Branch Development

Ever had your Pega rule changes mysteriously disappear after a teammate merged their branch? Here's why it happens — and how to fix it

For example, DevA, DevB, and DevC are three developers working on separate feature teams, and they all require the same rule for their development. Suppose the rule they all need to modify is an Activity, named ActivityInCommon. DevA, DevB, and DevC are each working in separate branches.

ActivityInCommon has a property configured in step 1 of the latest ruleset within the application.

Property-Set

Prop1 => Value1

In step number 1, DevA is adding a property and assigning it a value.

PropA -> ValueA

In step number 1, DevB is adding a property and assigning it a value.

PropB -> ValueB

In step number 1, DevC is adding a property and assigning it a value.

PropC -> ValueC

Assume DevA started first and he checks out the ActivityInCommon from the ruleset in the application and started coding into his branch. Similarly, DevB and DevC checks out the rule from the application ruleset and added his property set in step 1 in ActivityInCommon.

Now if DevA first checks in his changes, the step 1 in the activity will be looking like this.

Property-Set

Prop1 => Value1

PropA -> ValueA

Now if DevB first checks in his changes, the step 1 in the activity will be looking like this.

Property-Set

Prop1 => Value1

PropB -> ValueB

Now if DevC first checks in his changes, the step 1 in the activity will be looking like this.

Property-Set

Prop1 => Value1

PropC -> ValueC

Depending on who checks in first, the changes from the other two developers will be overridden in the application. Do you understand why this occurs? Yes, you guessed correctly. During the merge, Pega displays a warning such as Same rule is present in some other branch and there is conflict. This warning indicates that someone else is modifying the same rule, so you need to retrofit your changes with those of the other developer.

What is retrofitting? Consider the same scenario: DevA attempts to merge and notices a warning indicating that the same rule exists in DevB's branch as well. In this situation, DevA should notify DevB that he is committing his changes to the ruleset. After this notification, DevB needs to check out the rule from the ruleset again and apply his modifications on top of the rule altered by DevA. Once this step is completed, the ActivityInCommon, after both DevA and DevB have finalized their changes, will appear as follows.

Property-Set

Prop1 => Value1

PropA -> ValueA

PropB -> ValueB

Same process needs to repeat by DevC or rest of the developer if they are changing the same rule.

In summary, when multiple developers modify the same rule independently, whoever checks in last unknowingly overwrites the others' changes — Pega flags this with a branch conflict warning, but doesn't resolve it automatically. The fix is retrofitting: developers communicate check-in order, and each subsequent developer re-checks out the already-updated rule before layering their own changes on top, rather than overwriting from their stale branch. This sequential, communication-driven approach ensures all developers' contributions to a shared rule are preserved in the final version, rather than lost to the last save.