Issue 1:

Incorrect conflicts are detected even though the client is not using the Fast Release feature to deploy parallel changes.

Root cause:

False conflicts are being detected in artifacts that undergo multiple revisions (updates) within a single release. When a rule undergoes multiple updates through Standard change request, conflicts arise due to discrepancies in the "pxMergeSynchronized" property value compared to the deployed version's "pxUpdateDateTime" in the "pySaveRMRuleToBranch" activity.

Steps to Replicate:

1. A user selects a WHEN rule in a standard change request in the CDH portal using Revision Management. User resolves the change request.
2. The same steps are repeated to edit the same WHEN rule multiple times in multiple standard change requests in the same open revision.
3. Proceed with deployment, during this process, the conflict screen will present the WHEN rule as a conflict.
4. Note: This issue can occur with other rule types updated via standard change requests and it is not restricted to WHEN rules.

Resolution:

• All clients are advised to disable the Conflict Check screen in the Revision Deployment process. Please see the FAQ below for the steps to disable the screen.
  • Earlier we advised clients on Pega Infinity 23.x to apply HFIX-B1693. If you have already applied this hotfix, please be advised that this only partially resolves the problem. As such please disable the Conflict Check screen.
• Note: Merge conflicts may still occur in the Development environment during the pipeline execution. These conflicts are separate from the Conflict Check screen. These rule merge conflicts need to be evaluated and resolved manually in the Development environment.

Issue 2:

Incorrect rule updates after automatically resolving conflicts using the "Resolve automatically" option.

Root cause:

When shared rules exist between Standard change request and  1:1 Ops manager change requests (OpsCR), we have observed that conflicts are not accurately identified for these shared rules, resulting in the deletion of some rules. Shared rules include Decision Parameters (DDRs), Proposition Filters, and WHEN rules.

Steps to Replicate:

1. During the standard release, use OpsCR to update an action and include 2 Email treatments and 2 Web treatments.
2. Confirm that the Email Treatments DDR shows increases in the row count (e.g., 24 existing + 2 new rows for new treatments) in the branch, and the Web Treatments DDR includes newly added treatments (76 existing + 2 new rows for new treatments).
3. Resolve the OpsCR.
4. Create a Standard CR and update the Email Treatments DDR and Web Treatments DDR. Add new form fields to the DDRs. Complete the Standard CR.
5. Create a Fast release, update an action using OpsCR, and add 2 Email treatments and 2 Web treatments.
6. Deploy the Fast release.
7. Before deploying the revision of the standard release, encounter the same conflict screen. Upon clicking "Resolve automatically," the Email Treatments DDR was deleted from the branch, and the Web Treatments lost the 2 new treatments.

Resolution:

• All clients are advised to disable the Conflict Check screen in the Revision deployment process. Please see the FAQ below for the steps to disable the screen.
• For clients using Fast Release, please replicate the business changes completed in a Fast Release into the next Standard release. The feature that automatically merges changes from Fast Release to Standard release is now disabled.
• For example, if an Action called "Cash bonus on savings" was deactivated in the Fast Release but remains active in the Standard release, you must apply this change across both releases to maintain consistency and avoid potential business conflicts.

Frequently Asked Questions: