[object Object]

Three teams sharing one dev instance, all touching the catalog item form, all promoting through the same QA window. Update set collisions are guaranteed, and the platform’s merge UI does not solve them — it surfaces them. Survival requires process, not tools.

The collision pattern

Two update sets contain the same sys_id for the same record (a Business Rule, a UI Policy, a script include). Whichever set imports last wins. The other team’s change silently disappears. Nobody notices for a week.

Detection before deploy

Before promoting a batch, run the conflict detection query against the target environment’s sys_update_xml:

var ga = new GlideAggregate('sys_update_xml');
ga.addQuery('update_set', 'IN', updateSetSysIdList);
ga.addAggregate('COUNT');
ga.groupBy('name');
ga.groupBy('target_name');
ga.having('COUNT', '>', 1);
ga.query();

Every result row is a record touched by more than one update set in the batch. These are your merge candidates.

The triage workflow

For each conflict:

  1. Identify which team owns each update set
  2. Compare the XML side-by-side using the Update Set Preview diff view
  3. Decide: take A, take B, manual merge, or split into a follow-up set
  4. Document the decision in a Release Notes field on the destination update set

Never just promote and hope. The “hope” path is how production loses changes.

The batch promoter pattern

Adopt one named release manager per promotion window. They own the batch order, run the detection query, mediate the merge, and post the merge log to a release channel. The role rotates weekly so the knowledge spreads.

The sys_update_set_batch feature is underused. Group co-dependent update sets so they import as a unit. This solves the “set A imported but set B failed” partial state problem.

Branch by environment, not by feature

Trying to model Git-style feature branches in update sets is an anti-pattern. The platform model is environment-based: Default is your working set, you complete to a named set, and you promote forward. Force feature isolation with separate dev sub-instances if your team is large enough to need it.

What to do this week

Run the conflict detection query against your next promotion batch. If there are conflicts, do not promote until the triage workflow is complete. Document every merge decision in writing — the muscle memory pays back the first time something almost gets lost.

[object Object]
Share