ERP Login Outage at Month-End Close
At 08:10 on Monday, 420 of 1,200 employees cannot authenticate to the ERP system. Month-end close ends Wednesday at 17:00 and transaction entry is blocked; a read-only reporting portal still works. The service desk has logged 63 incidents in 20 minutes, 41 of them identical login failures. Monitoring shows the ERP application cluster healthy, but the SSO connector is logging 'token validation timeout'. A patching change was completed on the SSO servers Friday 22:00-23:30. There is no problem record. The service desk manager wants to know whether to declare a major incident, whether to open a problem, and what to do with the 41 duplicate tickets.
1. Using the default impact/urgency matrix, what priority should this incident carry? Justify impact and urgency separately and state the practical consequence for the response team.
Read the worked answer
Impact = 1 (High). 420 of 1,200 employees are affected and a business-critical process (transaction entry for month-end close) is blocked. Scope and business criticality both point to High.
Urgency = 1 (High). There is a hard deadline of Wednesday 17:00 and only a partial workaround (read-only reporting). Damage grows with every hour.
Matrix: Impact 1 x Urgency 1 = Priority 1.
Consequence: the P1 response commitment applies - engage the on-call resolver group immediately, drive through the major incident process (dedicated incident commander and communications cadence), and notify senior stakeholders rather than letting the ticket sit in a queue. Do not downgrade to P2 just because the ERP application itself is healthy; the matrix scores business effect, not component status.
2. How should the 41 duplicate incidents and the lead record be handled so reporting and communications stay clean?
Read the worked answer
Pick one incident as the parent (typically the first, or the one already carrying the strongest work notes) and link the rest as child incidents using the parent/child relationship. Then:
- Work and communicate from the parent only; children collect calls, not parallel investigations.
- Resolve the parent with a single authoritative resolution; close the children against the parent so the resolution is inherited rather than re-typed with drift.
- Keep the 22 genuinely distinct reports (different users, different error text) as their own incidents linked to the parent so trend data is not destroyed.
Why not just close the duplicates as 'no action'? Because that loses the caller-to-CI linkage used by reporting and by any later problem investigation. Why not merge them into one record? Because ServiceNow does not merge incidents; the parent/child pattern preserves both the volume signal and the audit trail.
3. Should a problem be opened now, and how should the suspected patching change be handled?
Read the worked answer
Yes, open a problem now - in parallel, not instead of restoration. The evidence supports it: multiple incidents, a shared symptom on a shared CI, no known root cause, and a recent change that is a plausible cause. Create the problem from the parent incident, link all related incidents and the affected CIs, and route it to the problem team.
Do not delay service restoration for root cause analysis. Incident restores service (rollback, failover, connector restart); problem prevents recurrence.
On the change: attach the Friday change record to the problem and review its back-out plan. If reverting is the fastest restoration path, execute it under the incident, and if the freeze/approval rules require it, raise the revert as an emergency change with ECAB approval and document why. What you must not do is have a team member quietly undo the patch off-record - that is an unauthorized change and destroys the causal evidence the problem team needs.