Update set commit conflict: record modified in both sets

Two development teams modified the same record (form, field, business rule, etc.) in different update sets that were created from overlapping baselines, causing conflicting changes when committing. (high likelihood)

An update set was retrieved from another instance where the same records had been modified locally, creating conflicts between remote and local changes. (high likelihood)

A previously committed update set modified records that are also present in the current update set being committed, and the changes are incompatible. (medium likelihood)

Multiple update sets containing the same customization were committed out of sequence, causing version conflicts in the sys_update_xml table. (medium likelihood)

System cloning or data import operations modified records that exist in pending update sets, creating unexpected conflicts during commit. (low likelihood)

Step 1: Navigate to System Update Sets > Local Update Sets (or Retrieved Update Sets) and open the conflicting update set to view the detailed error message and identify which specific records are in conflict.

Step 2: Go to System Definition > Tables and open the sys_update_xml table, then filter by update_set field using the conflicting update set's sys_id to see all records in the set.

Step 3: For each conflicting record, compare the payload XML in the sys_update_xml record with the current state of the target record in the system to understand the differences.

Step 4: Use the Update Set Preview functionality by navigating to System Update Sets > Preview Update Set to analyze conflicts before committing and see side-by-side comparisons.

Step 5: Resolve conflicts by either manually editing the target records to incorporate both changes, or by removing conflicting update XML records from the update set if they're no longer needed.

Step 6: Create a new update set and manually recreate the desired final state of conflicting records, then test thoroughly before committing the resolution update set.

Step 7: If conflicts are too complex, consider backing out recently committed conflicting update sets using System Update Sets > Backed Out Update Sets, resolve conflicts offline, and recommit in proper sequence.

Step 8: After resolving all conflicts, retry committing the update set and verify that all changes were applied correctly by testing the modified functionality.