Interview Q&A Practice

ACLs define what can be done — read, write, create, delete — and at what level: table, field, or even row. Roles define who someone is. On their own, roles don't actually restrict anything — they're just a label assigned to users or groups. They become powerful when an ACL references them. So for example, I could create an ACL that says "only users with the 'customer_viewer' role can read this table." It's also worth knowing that ServiceNow denies access by default if no ACL exists — so you're building permissions up, not locking things down after the fact. Think of the ACL as the lock, the role as the key.

Users are stored in sys_user and can be provisioned manually, via CSV import, or through LDAP/SSO for automated provisioning and deprovisioning. Groups in sys_user_group serve multiple purposes: assignment routing, approval workflows, notification subscriptions, and role inheritance. Best practice is to always assign roles at the group level rather than to individual users — it's cleaner from an audit perspective, and when someone moves teams you just change their group membership. Groups can also be nested so child groups inherit parent roles, which maps well to org hierarchies.

Update sets are a wrapper that captures all configuration changes (customer updates) in a development instance. Think of them as version control for ServiceNow config. You create one, select it as current, make your changes, then promote it through Dev → Test (UAT) → Prod — never skip steps. Not everything is auto-captured (data changes, some form changes) so always verify. Good hygiene matters: proper naming conventions, descriptions, dates. Update sets can also be backed out if something goes wrong post-commit, which is your safety net.

itil is the baseline for anyone working within ITSM modules — incident, problem, change. It grants fulfiller views and actions. admin bypasses most ACLs and gives unrestricted platform access — use sparingly, and some orgs use time-boxed admin access instead of permanent. snc_internal is a ServiceNow internal role — you'd never assign it but you'll see it referenced in base system ACLs. Key principle throughout: least privilege. Give people exactly what they need, nothing more.

A UI Policy is client-side — it controls the form experience: hiding/showing fields, making things mandatory or read-only. A Business Rule is server-side and runs on database operations (before/after/insert/update/delete). Quick test: am I affecting the form or the data? Form = UI Policy. Data = Business Rule. Watch out — UI Policies do have a server-side checkbox but it's discouraged for performance reasons.

Both live in the Service Catalog and look identical to the end user. The difference is what happens behind the scenes. A Catalog Item creates a Requested Item (RITM) and associated tasks — it's for ordering things (laptop, access, new hire setup). A Record Producer creates a record directly on a target table (like an incident). So if you want users to raise an incident through the portal without seeing the incident form, you'd use a Record Producer. Catalog Item = ordering something. Record Producer = reporting something.

Form Layout (Configure → Form Layout) is the classic drag-and-drop approach for arranging fields into sections and columns. Form Designer is the more modern visual interface that does the same thing but lets you configure field properties inline too. Both achieve the same result. Key thing to know: forms have views — you can have different layouts for different roles (itil view vs self-service view). Always check which view you're editing. And while form changes should be captured in update sets, always verify they were actually picked up.

Configuration = using built-in tools (form layout, UI policies, workflows, system properties). These are upgrade-safe. Customization = writing custom code or modifying base system files — these can break during upgrades. ServiceNow's philosophy is configure first, customize only when there's no other way. When you do customize, document it thoroughly. This is also a values question — Daniel wants to hear that you reach for out-of-the-box solutions before writing code.

The core modules are Incident, Problem, Change, and Request — and the power is in how they connect. Incident = restore service ASAP when something breaks. Problem = root cause investigation when a pattern emerges. Change = implement the fix properly with risk assessment and approvals. Request = standard service needs through the catalog. The flow: multiple incidents → problem raised → root cause found → change raised to fix it → problem resolved. The CMDB ties it all together by mapping what infrastructure is affected.

An Incident is a symptom — something is broken or degraded, restore service fast. A Problem is the underlying cause. Classic example: 10 users can't access email = 10 incidents. Mail server ran out of disk space = the problem. Incident goal: restore service. Problem goal: prevent recurrence. Not every incident needs a problem — only raise one when there's a pattern, an unknown root cause, or a major incident that warrants deeper investigation.

Standard = pre-approved, low-risk, repeatable — no CAB needed. Normal = needs assessment and approval, goes through CAB or peer review. Emergency = urgent production fix, expedited approval, documented after the fact. Every change regardless of type needs: risk assessment, implementation plan, backout plan, and testing evidence. No cowboy deployments.

The CMDB is the Configuration Management Database — a map of your IT infrastructure. It stores Configuration Items (CIs) — servers, applications, databases, network devices — and crucially the relationships between them. If a server goes down, the CMDB tells you which applications and business services are affected. It ties into ITSM: incidents link to affected CIs, changes reference what they're modifying. Critical caveat: a CMDB is only useful if it's accurate. Stale data is worse than no data — it leads to wrong decisions.

1. Review release notes — new features, deprecations, breaking changes. 2. Clone prod into a sub-production instance and run the upgrade there first. 3. Review skipped records — these are where your customisations clash with ServiceNow's updates, each needs a decision: take theirs, keep ours, or merge. 4. Run Instance Scan to catch best practice violations. 5. Thorough UAT — critical workflows, integrations, scheduled jobs, custom scripts. 6. Schedule maintenance window, upgrade prod, validate, monitor closely for first few days.

Instance Scan is a built-in health check tool that evaluates your instance against ServiceNow best practices. It scans for performance issues, manageability concerns, upgrade risks, and security vulnerabilities. It produces a findings report with severity ratings and remediation guidance. Key thing: run it regularly as part of platform governance, not just before upgrades. Findings should be triaged and tracked like any other backlog item. You can also create custom scan checks for org-specific standards.

Key areas to watch: stats.do (system diagnostics) for node health, memory, active transactions. Scheduled jobs for failures, long-running or stuck jobs. System logs and slow query logs to spot trends before they become incidents. Email queue — notifications are critical for workflows. Instance Scan on a regular cadence. Ideally surface all of this in a single health dashboard so the team has a pulse without digging through individual modules.

Change management discipline: everything through Dev → Test → Prod, no exceptions. Update set hygiene: proper naming, descriptions, never using the Default set for real work. Role audits: regular review of who has admin or elevated access, applying least privilege. Instance Scan on a regular cadence with findings tracked as backlog. Documentation: every customisation documented — what, why, when, who. For Genesys specifically, GDPR matters — EU customer data needs clear controls, which is where ACLs, data policies, and EU-based admins come in.

Reports are built by selecting a table, applying filters, choosing a chart type (bar, pie, trend, list), and grouping the data. Dashboards collect multiple reports into a single view in a grid layout. Reports can be scheduled for automated email delivery. For advanced needs, Performance Analytics tracks KPIs over time with indicators, breakdowns, and targets. Most important principle: every report should help someone make a decision. If a dashboard doesn't drive action, it's just noise.

Incidents: open vs resolved trend, MTTR, breakdowns by priority/category/assignment group. Changes: by type, success/failure rate, change calendar. Requests: catalog item popularity, fulfilment time. SLA attainment by priority — leadership always asks this first. Platform health: scheduled job failures, update set activity, user adoption. Bundle into role-specific dashboards: one for ops, one for management, one for the platform admin team.