The Business Rule That Never Arrived
A release moves from dev to test to prod through update sets. The release contains 120 changes across 9 update sets. After commit in prod, the business rule 'Set VIP priority' is missing, although it works in dev and test. The developer says she created it while her current update set was 'VIP Enhancements', but that set shows 87 records and several rows are in state Ignore. A UI action in the same release points to a script include that was committed, but the UI action's condition references a role that does not exist in prod. Preview in test showed no problems. Prod also has a manually created copy of the business rule from a hotfix last month, now inactive.
1. Diagnose why the business rule is missing in prod.
Read the worked answer
Most likely the business rule was not in the committed set. 'VIP Enhancements' has 87 records and some are in Ignore, meaning those records were deliberately or accidentally skipped. A record can also be missed if the developer's current update set changed (changes go to the Default set), if the record is in a different update set, or if the wrong set was retrieved/committed.
The inactive manual hotfix copy in prod is a separate record; it does not satisfy the missing active business rule. The missing role is another dependency: the UI action committed, but its condition references a role record that was not in any committed set.
2. Why did preview in test show no problems?
Read the worked answer
Preview and commit check record dependencies and conflicts in the update set; they do not validate script references such as a role name inside a condition, and they do not force an ignored record to commit. Preview also cannot detect that a developer made a change outside the intended update set. 'No preview problems' therefore means the records that were in the set looked internally consistent, not that the release was complete.
3. What do you do now, and what prevents a repeat?
Read the worked answer
Retrieve the correct update set(s) and set ignored rows back to commit if they are required; commit in dependency order (role before the UI action and business rule). Compare the business rule's sys_update_xml in dev and prod. If prod has a manual copy, decide whether to update it or delete it and let the update set create the record. After commit, verify the business rule is active, the role exists, and the condition evaluates.
Prevention: one update set per story, no Ignore without a documented reason, and a release checklist listing records and dependencies (roles, script includes, tables). Add a post-commit smoke test. For scoped apps, use the application repository instead of update sets.