Top ServiceNow Admin Interview Questions & Answers (2026)

To read a field a user must pass both a table-level read ACL on incident and a field-level read ACL for incident.description. The platform matches the most specific rule first, so it looks at incident.description, then the parent task.description, then wildcard rules. Within an ACL, every condition that's defined, the required roles, the condition and the script, must pass. Newer releases also have Deny-Unless rules, which block access unless their conditions pass. So here I'd suspect a field ACL with a role or condition this user fails. I'd impersonate them, turn on security debugging or use the access analyzer, find the failing rule, and elevate to security_admin before changing it.

I'd use an import set. Loading the spreadsheet creates a staging import set table, then a transform map moves the data into the target table with field maps for each column. To avoid duplicates I set coalesce on a unique field, like an employee number or asset tag, so matching rows update existing records instead of inserting new ones. If no single field is unique I can coalesce on a combination. For reference fields I check how values should match, and I use transform scripts for cleanup. I always run a small sample in a sub-production instance first, review the import log for errors, and keep the transform map so the import can be repeated.

Flow Designer, which now lives inside Workflow Studio, is my default for business processes: multi-step logic with approvals, tasks, notifications, waiting on conditions, or calling other systems through IntegrationHub spokes. It's readable by process owners, reusable through subflows and actions, and easier to change without a developer. A business rule is better for small, fast server-side logic tied to a database operation, like setting a field before insert, aborting an invalid update, or copying a value to a related record. I wouldn't put a long approval process in a business rule, and I wouldn't use a flow just to default one field on save, because that adds overhead.

The CMDB holds configuration items, servers, applications, network gear and business services, plus the relationships between them, so incidents and changes can show impact. Everything descends from the cmdb_ci base table into classes. It goes stale when people update it by hand and nobody owns it. To keep it healthy I'd populate it automatically through Discovery or Service Graph Connectors, which run data through the Identification and Reconciliation Engine so the same server from two sources doesn't become two records. I'd assign owners per class, use the CMDB Health dashboard to track completeness, correctness and compliance, and retire CIs through a defined lifecycle instead of deleting them.

The user fills in the catalog item's variables and submits, which creates a request, sc_request, with a REQ number. Each item ordered becomes a requested item, sc_req_item or RITM, and the item's flow drives what happens next: usually a manager approval, maybe a second approval over a cost threshold, then catalog tasks, sc_task, assigned to groups like hardware or desktop support. As tasks close, the RITM moves through its stages and closes, and when all items are done the request closes. I'd design variables with clear labels and help text, use variable sets for fields reused across items, and use catalog UI policies to show fields only when they're needed.