‹ All interview questions

Architecture

In a 10-developer team working on a single shared dev instance, you're experiencing frequent Update Set…

Senior · ServiceNow · Feb 2026

The question

In a 10-developer team working on a single shared dev instance, you're experiencing frequent Update Set conflicts during promotion to UAT. Last week, 3 out of 5 Update Sets failed preview with 40+ conflicts each, mostly on Business Rules and Script Includes, delaying a critical release by 2 days. Team reports 'I didn't know that record was in someone else's US'. Describe your diagnosis approach to identify root causes, list 3+ solution options with trade-offs, and explain production deployment considerations. What metrics would you track to prevent recurrence? Bonus: Show a code snippet that detects if a record is in another dev's active Update Set (hint: query sys_update_version).

What This Question Really Tests

Update Set conflicts occur when multiple developers modify the same record in different Update Sets on a shared instance, detected during preview as collisions between local/target versions and incoming US changes. In a 10-dev team, root causes include lack of visibility into others' US contents, no merge discipline, and parallel work on shared objects like BRs/UI Policies. Diagnosis starts with US preview logs (sys_update_xml), conflict counts per table, and querying sys_update_version for overlapping records across USes.

The Solution

Diagnosis Script (Problem Detection): This Script Include checks if current record is in another active US, alerting devs proactively.

var CheckUSConflict = Class.create();
CheckUSConflict.prototype = {
    initialize: function() {},
    check: function(gr) { // gr = GlideRecord of current record
        var answer = {conflict: false, usName: '', owner: ''};
        var usv = new GlideRecord('sys_update_version');
        usv.addQuery('name', gr.getTableName() + '_' + gr.sys_id);
        usv.addQuery('state', 'current');
        usv.query();
        if (usv.next()) {
            var us = new GlideRecord('sys_update_set');
            us.get(usv.source);
            if (us.state == 'in_progress' && us.user != gs.getUserID()) {
                answer.conflict = true;
                answer.usName = us.name;
                answer.owner = us.user;
            }
        }
        return answer;
    },
    type: 'CheckUSConflict'
};

Usage: Call from BR on form load: if (new CheckUSConflict().check(current).conflict) gs.addErrorMessage('Record in ' + answer.usName + ' by ' + answer.owner);

Senior Considerations

  • Diagnosis Depth: 'Check the preview logs' is the entry-level answer; go deeper by querying sys_update_set/state=in_progress, cross-referencing sys_update_version by table/sys_id, and tracking conflicts per table via reports; identify hot tables (e.g., sys_script >50% conflicts).
  • Solution Options & Trade-offs: 1) Proactive Alerts (above code + BRs on key tables): Low cost, high adoption; trade-off: alert fatigue if overused. 2) Branching US Strategy: Devs pull base US, work in personal US, merge via US Merger plugin; prevents overlaps but requires discipline/merge reviews (trade-off: +20% overhead). 3) Scoped Apps/Private Dev: Migrate to app dev (studio.perf); isolates changes; trade-off: refactor effort, not for platform customizations. 4) CI/CD (great answer): NSD/Jenkins auto-detects conflicts pre-merge; scales to 10+ devs but needs setup/infra investment.
  • Prod Considerations: Never commit conflicted US—always preview twice, resolve via 'Compare w/ Local'/'Accept Remote' documenting in US notes. Post-prod: Monitor syslog for skipped updates, use Update Set Analyzer for drift. For upgrades, capture resolutions in separate 'upgrade_fix' US before clone.
  • Metrics for Prevention: Conflicts/US, time-to-resolve, US merge rate, dev-per-US; target <5% conflict rate via weekly US hygiene audits.
  • Edge Cases: Default US pollution, hotfixes desyncing instances, cross-scope conflicts—great answers discuss sys_scope/state=loaded skips.