20 Real-Time ServiceNow Scenario-Based Interview Questions — Answered

These are detailed answers for the most commonly asked ServiceNow Developer / Admin / ITSM scenario questions in interviews at companies like PwC India.

---

1️⃣ Duplicate incidents are getting created automatically from emails. How will you troubleshoot it?

Root Cause Areas to Check:

• Go to System Mailboxes → Inbound Actions and check if duplicate inbound action rules are mapped to the same mailbox or overlapping conditions.
• Open the Email Log (sys_email table) and filter by the email’s Message ID — if you see the same email processed multiple times, the mailbox polling is duplicating.
• Check if the mailbox is configured on more than one MID Server or if polling intervals are overlapping.
• Review the Inbound Action script — it may be creating a new incident without first checking for an existing open one.
• Verify the Correlation ID field on the incident — this is how ServiceNow links email threads to existing records and prevents duplicates.

Pro Tip: Add a duplicate check in your Inbound Action script using gr.addQuery('correlation_id', email.message_id) before creating a new incident.

---

2️⃣ SLA is breaching even though tickets were resolved on time. What will you check?

Root Cause Areas to Check:

• Review the SLA Definition — check the Start Condition, Stop Condition, and Pause Condition. An incorrect stop condition means the SLA clock doesn’t stop at resolution.
• Open the Task SLA records on the incident and check the Stage field. If it still shows “In Progress” after resolution, the stop hasn’t triggered.
• Inspect the SLA Workflow — confirm the stop trigger (e.g., State = Resolved) is correctly mapped.
• Verify timezones — the SLA Schedule and the user/assignment group timezone must align. Mismatches cause calculation errors.
• Check if the incident was re-opened after resolution — re-opening can restart the SLA clock depending on configuration.
• Use the SLA Timeline on the incident form to visually trace when each SLA stage changed.

Pro Tip: Use the Script Debugger with sla.js to trace SLA logic in real time on a sub-production instance.

---

3️⃣ Flow Designer flow is triggering multiple times for the same record. How will you stop recursion?

Root Cause Areas to Check:

• Check the flow trigger — if set to Record Updated, confirm the flow itself isn’t modifying a field that matches the trigger condition again.
• Use a guard flag field (e.g., u_flow_processed boolean) — check it at the start of the flow and set it before the flow ends to prevent re-entry.
• Review all Action steps — if any action updates the triggering record, that update re-evaluates the trigger condition.
• Check if multiple flows have overlapping trigger conditions on the same table.
• Under Flow Properties, check if “Limit to one run per record” option is available and enable it.

Pro Tip: Add a condition action at the very top of the flow: IF u_flow_lock = true → End Flow, then set that field to true as your first action step.

---

4️⃣ Discovery is creating duplicate CIs in CMDB. How will you resolve it?

Root Cause Areas to Check:

• Review the Identification and Reconciliation Engine (IRE) configuration — check if identifier rules for the CI class (e.g., serial number, hostname) are correctly set.
• Open the Discovery Log and CMDB Remediation tab for reconciliation errors.
• Use the CMDB Health Dashboard to identify duplicate CI records and compare their attributes.
• Go to Configuration → CI Class Manager and inspect Identification Rules — weak or missing identifiers cause new CI records instead of updating existing ones.
• Run the CMDB Deduplication remediation task to merge identified duplicates.
• Check if the same CI is being discovered from multiple IP ranges by different probes on different MID Servers.

Pro Tip: Set identifier priority in IRE as: Serial Number > Asset Tag > Hostname. Never use IP address alone — it changes in DHCP environments.

---

5️⃣ REST API integration is failing with HTTP 401 Unauthorized. How will you debug authentication issues?

Root Cause Areas to Check:

• Check the REST Message configuration — verify the endpoint URL, HTTP method, and authentication type (Basic Auth, OAuth 2.0, or API Key).
• For Basic Auth: confirm the username and password are correct, and the account is not locked or expired on the target system.
• For OAuth 2.0: check if the access token has expired. Use the OAuth Entity Profile to refresh or regenerate tokens.
• Test the endpoint directly using REST API Explorer in ServiceNow or via Postman to isolate whether the issue is in the config or on the target system.
• Check if the target system requires IP whitelisting — the MID Server or instance IP may need to be added.
• Review Outbound HTTP Requests under System Logs to see the exact request headers and response received.

Pro Tip: Always store credentials in Connection & Credential Aliases, not hardcoded in scripts. This allows credential rotation without touching code.

---

6️⃣ Users have correct roles but still cannot access records. How will you troubleshoot ACLs?

Root Cause Areas to Check:

• Enable the ACL Debugger — go to Security → Access Control and turn on debug mode for the affected user’s session.
• Impersonate the user and attempt to access the record — the debug console shows exactly which ACL rule is blocking access.
• Check for row-level security — a Read ACL may have a condition like assigned_to = current user which restricts access based on record data, not just role.
• Review ACL order and specificity — a more specific ACL can override a general permissive one.
• Verify if the user’s roles are directly assigned or via a group — group membership caching sometimes requires a session refresh to take effect.
• Check Data Policies and Client Scripts — fields being hidden by scripts can look like an ACL issue but are not.

Pro Tip: Append ?acl_debug=true to any record URL to see a live ACL evaluation overlay without needing full admin access.

---

7️⃣ Requested Items are getting created but Catalog Tasks are missing. What could be wrong?

Root Cause Areas to Check:

• Check the Catalog Item’s Process Engine — verify it’s linked to a Flow or Workflow that includes a Create Catalog Task step.
• Inspect the linked flow/workflow — if a condition on the task activity isn’t met, the task generation step is silently skipped.
• Verify the sc_task table isn’t filtered or hidden by a View Rule for the affected user.
• Check if an Order Guide or multi-item cart is causing the process engine to skip individual item flows.
• Review recent updates to the Catalog Item or process engine — a mis-saved change can remove task generation steps.
• Check Fulfillment Group assignment — tasks missing a group assignment can fail silently in some configurations.

Pro Tip: After ordering, always query the sc_task table directly using the RITM number to confirm whether task records are being created at all.

---

8️⃣ Emergency Changes should bypass CAB approvals while Normal Changes should follow complete approval flow. How would you configure this?

Root Cause Areas to Check:

• In Change Management → State Models, create separate state flows for Emergency and Normal change types.
• For Emergency Changes: set the Approval policy to Not Required or route to a single Emergency CAB approver using an Approval Rule with condition type = Emergency.
• For Normal Changes: configure the Approval Rule to require full CAB group sign-off before the change reaches Scheduled state.
• Use the CAB Workbench and associate CAB meetings with Normal change type only — this keeps Emergency changes out of regular CAB queues.
• Add a UI Policy or Business Rule to enforce mandatory risk/impact fields on Emergency changes as a compensating control.

Pro Tip: Always use Change Type as the primary condition in Approval Rules. Avoid hardcoding approval logic in Business Rules — use the native Approval Engine for traceability.

---

9️⃣ Incident assignment rules are not working for one specific group. How will you verify?

Root Cause Areas to Check:

• Check Assignment Lookup Rules under System Policy — verify the rule condition doesn’t have conflicting logic that causes this group to be skipped.
• Check rule priority/order — a higher-priority rule may be matching first and overwriting the intended group assignment.
• Confirm the Assignment Group record is active and has members.
• Look for a Business Rule or Inbound Action overwriting the assignment after the rule runs.
• Add temporary gs.log() statements to the rule script to trace execution in a non-production environment.
• Verify the rule applies to the correct table (Incident vs Task) and correct conditions (category, subcategory, service).

Pro Tip: For complex assignment logic, use a Business Rule with After timing instead of the native assignment rule engine — it gives more control and is easier to debug.

---

🔟 A workflow is stuck in “Running” state for several hours. How would you investigate it?

Root Cause Areas to Check:

• Go to Workflow → Live Workflows — find the stuck context and identify which activity it is currently paused on.
• Common causes: waiting for an approval that was never created, a timer activity with incorrect duration, or a subflow that errored silently.
• Check the Workflow Log on the context record for error messages or unhandled exceptions.
• If stuck on approval: check the sysapproval_approver table — the approval record may not have been created for the approver.
• For stuck timers: verify the Workflow Timer scheduled job is active and running.
• To recover: use Cancel on the workflow context and re-trigger if safe, or manually advance the context using the Workflow Editor.

Pro Tip: In production, prefer Flow Designer over Legacy Workflow — it has better error handling, execution history, and recovery options.

---

1️⃣1️⃣ High-priority incidents are not triggering notifications. What areas will you check?

Root Cause Areas to Check:

• Go to System Notification → Email → Notifications — verify the notification is Active and the condition correctly targets Priority = 1 - Critical.
• Check the “Who will receive” tab — ensure the right recipient group or role is configured.
• Review Notification Preferences for individual users — they may have opted out of email notifications.
• Check Email Outbox and Email Log — emails may be generated but failing to send due to SMTP configuration issues.
• Look for an active Notification Stop Rule that may be suppressing high-priority notifications.
• Check if the notification has a Schedule (Business Hours) configured — incidents created outside those hours will not trigger the notification.

Pro Tip: Temporarily add your own email to the recipient list and trigger a test incident to confirm whether the issue is with notification triggering or email delivery.

---

1️⃣2️⃣ A Business Rule is slowing down form loading. How will you identify the root cause?

Root Cause Areas to Check:

• Append ?stats.do to the record URL to see a breakdown of Business Rule execution times on that form load.
• Use the Script Debugger to step through the Business Rule and locate slow operations.
• Look for Business Rules running with Display = true that execute expensive GlideRecord queries on every form load.
• Check for GlideRecord queries inside loops, or queries without a row limit — these can scan millions of records.
• Review if the rule can be replaced with a Client Script or Data Policy that runs client-side instead.
• Check for synchronous external callouts or REST API calls being made from within the Business Rule.

Pro Tip: Use GlideAggregate for count operations instead of iterating with GlideRecord. Always use gr.setLimit(1) when you only need to check if a record exists.

---

1️⃣3️⃣ Users should only see catalog items related to their department. How would you implement this?

Implementation Approach:

• Use User Criteria on each Catalog Item — in the item’s “Available For” section, add a User Criteria record that checks user.department.
• Create a User Criteria script: return gs.getUser().getDepartmentID() == current.u_department;
• Apply User Criteria at the Catalog and Category level too — this hides entire sections for irrelevant departments.
• Test by impersonating users from different departments and verifying the Service Catalog view is filtered correctly.

Pro Tip: Do not use ACLs for catalog item visibility — User Criteria is the native, supported approach. ACLs control record access, not catalog browsing behavior.

---

1️⃣4️⃣ MID Server is down and Discovery stopped working. How will you troubleshoot it?

Root Cause Areas to Check:

• Check MID Server → Servers — look at the Status, Last Heartbeat, and Validated fields.
• Log into the MID Server host machine and verify the MID Server Windows Service or Linux daemon is running.
• Review MID Server Logs at agent/logs/agent0.log — common errors include proxy failures, memory issues, or credential expiry.
• Verify network connectivity — the MID Server must reach the ServiceNow instance on port 443, and reach discovery targets on required ports (WMI, SNMP, SSH).
• Check credentials used by the MID Server — expired SNMP, WMI, or SSH credentials will block all discovery.
• Restart the MID Server service and monitor heartbeat recovery on the instance console.

Pro Tip: Always deploy at least two MID Servers per environment for failover. Use MID Server Clusters for high-availability discovery setups.

---

1️⃣5️⃣ One approval rejection should cancel the complete request automatically. How would you configure this?

Implementation Approach:

• In the Flow Designer flow, use an Ask For Approval action and set the approval type to “Anyone Rejects”.
• On the Rejected branch, add an Update Record action to set the Request (sc_request) state to Rejected/Cancelled.
• For multi-stage approvals: use subflows per stage and propagate rejection status back to the parent flow.
• If using Legacy Workflow: add an If activity after the Approval activity — condition Approval State = Rejected → route to a Cancel transition.
• Include a rejection notification to the requester as part of the rejected branch.

Pro Tip: Use “First Response” approval mode when you want any single approver’s action (approve or reject) to immediately decide the outcome — this speeds up the process significantly.

1️⃣6️⃣ Change conflict detection is not working correctly. What could be the possible reasons?

Root Cause Areas to Check:

• Verify the Change Collision Detector plugin is activated — go to System Definition → Plugins and confirm it’s active.
• Check Conflict Rules in Change Management settings — these define what constitutes a conflict (same CI, overlapping time window, same team).
• Ensure Affected CIs are populated on the Change record — conflict detection is entirely based on CI overlap.
• Verify the Planned Start and End Date fields are filled in — conflicts are compared within these time windows.
• Check if the Check Conflicts Business Rule or Scheduled Job is active and not throwing errors.
• Review if a recent upgrade or customization has overridden the out-of-box conflict detection script.

Pro Tip: Click the “Check Conflicts” UI Action button on the Change form manually to see live conflict detection results — this is the fastest way to debug and isolate the issue.

---

1️⃣7️⃣ Reports are taking too long to load in production. How would you optimize performance?

Root Cause Areas to Check:

• Use Performance Analytics indicators instead of on-demand reports for large datasets — PA pre-calculates data on a schedule, eliminating real-time query load.
• Add database indexes on frequently filtered report fields — raise a ServiceNow HI request for index creation on high-traffic tables.
• Simplify report conditions — remove nested OR conditions where possible, as these force full table scans.
• Switch to Scheduled Reports that run off-hours and are emailed to users, rather than being loaded on-demand during peak hours.
• Limit the date range in report filters — avoid “All time” queries on large tables like task, incident, or sys_log.
• Use Report Source caching for commonly shared report data sets.

Pro Tip: Check the Slow Query Log in ServiceNow’s HI portal to identify which specific queries are flagged — this gives you the exact table and filter to optimize first.

---

1️⃣8️⃣ Email notifications are getting triggered twice. How will you debug the issue?

Root Cause Areas to Check:

• Search for duplicate Notification records — look for notifications with the same name or overlapping conditions on the same table.
• Check Business Rules for gs.sendEmail() calls — a script-based email may be firing in addition to the declarative notification record.
• Open the Email Log (sys_email) filtered by the recipient email and time window — two distinct notification records generating emails will both appear here.
• Check if the record update that triggers the notification is itself happening twice (two Business Rules updating the same field).
• Review Inbound Actions — an email reply that updates a field, combined with a notification on that field update, can create a duplicate loop.
• Temporarily deactivate notifications one at a time to isolate which one is the extra trigger.

Pro Tip: Add a boolean guard field like u_notification_sent as a notification condition — check it’s false before sending, then set it to true. This is especially useful for one-time lifecycle notifications.

---

1️⃣9️⃣ A UI Action should only appear for managers and admins. How would you configure it?

Implementation Approach:

• Open the UI Action record and set the Condition field: gs.hasRole('itil_manager') || gs.hasRole('admin')
• Alternatively, use the Roles related list on the UI Action — add the required roles directly there.
• Test by impersonating a user with only the itil role — the button should not appear.
• For dynamic conditions (e.g., “manager of the assigned group”), write a script in the Condition field using gs.getUser() and group membership checks.

Pro Tip: Never rely on UI Actions alone for security. Always pair visibility restrictions with a server-side ACL or Business Rule that validates the same condition — UI Actions are a UX control, not a security boundary.

---

2️⃣0️⃣ A catalog item works for admins but fails for end users. How would you troubleshoot the issue?

Root Cause Areas to Check:

• Impersonate the end user and reproduce the exact error — note the error message or behavior.
• Check User Criteria on the catalog item, category, and catalog level — the user may lack visibility access.
• Inspect catalog item variables and variable sets — some may have ACL restrictions that block non-admin users from reading or writing values.
• Review the process engine (Flow or Workflow) — check if any step is missing the “Run as System” option, causing permission failures mid-execution.
• Look for gs.hasRole('admin') hard-checks in Client Scripts, Catalog Client Scripts, or flow scripts — these fail silently for end users.
• For flows that call integrations or update other tables, ensure the running user has the required roles or the step is set to run as System.

Pro Tip: Always test catalog items by impersonating a real end-user account before go-live. Admin sessions bypass many platform restrictions — what works for admins regularly fails for end users.

---

Today’s ServiceNow interviews test how you think under real production pressure — not just theory. Master these troubleshooting patterns and you’ll stand out in any interview.

Found this helpful? Drop a comment and share with your network! 🚀