A single team with one update set in flight is a solved problem. Three teams with overlapping changes is where update set strategy actually matters. Without a protocol, you get conflicts that surface only at deployment time, midnight calls about lost field changes, and an eventual collapse to “everyone use one big update set.”
Scope changes per team, not per release
Where possible, give each team its own scoped application. Within a scope, update sets cleanly capture changes without bleeding into other teams’ work. Cross-scope dependencies are explicit and reviewable. The scope boundary is the cleanest version of “ownership.”
Name update sets with a strict convention
TEAM-TICKET-shortdesc-DATE as the convention. Example: PLAT-CHG12345-add-cmdb-relation-2026-04-28. The team prefix tells you who owns it, the ticket links to the work item, the description gives a quick read, the date helps sort. Without convention, update set lists become unscanable within weeks.
One ticket, one update set
Resist the urge to roll multiple changes into one update set. If a change has to be reverted, you want to revert exactly that change, not the four other things bundled with it. The discipline of “one ticket per update set” pays back tenfold during incident response.
Use a shared “in flight” register
Maintain a simple table or wiki page listing update sets currently in flight per team, with the artifacts they touch (table, business rule, UI policy). Before starting work on a heavily shared artifact, check the register. The five seconds of coordination prevents the five hours of merge.
Promote in dependency order, not in author order
When two update sets touch related artifacts, the order of promotion matters. The downstream-dependency set must promote after the upstream. Build a dependency graph at code review time, not at deployment time. Surprises during a Friday evening promotion window are expensive.
Lock the target during promotion
When promoting to test, prod, or any shared environment, set a lock flag (a sys_property works) that blocks other teams from initiating their own promotion until yours completes. Concurrent promotions to the same environment are how update sets end up in “Ignore” state with no clear cause.
Review the preview every time
The Update Set Preview shows collisions before they become problems. Many teams click through it as a formality. Train the team to actually read the collisions and resolve each one explicitly, not “Accept Remote Update” by default. Five minutes of preview review prevents most of the post-deploy surprises.
Backout sets are not optional
For every promotion to production, an automated job should snapshot the target instance’s current state of changed artifacts into a “backout” update set captured before the new set is committed. If the new set causes problems, the backout set is the rollback path. Without it, rollback is “manually re-edit each field,” which never works under time pressure.
What to do this week: agree on a naming convention with your parallel teams and stand up a shared in-flight register, even if it is just a wiki page.
