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_processedboolean) — 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 userwhich 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.doto 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, orsys_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
itilrole — 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! 🚀
