Technical Interview Prep

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" — and then layer on a second ACL that prevents write or delete access entirely. That gives you real defence in depth: the ACL sets the rule, the role determines who the rule applies to. 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.

Users are stored in the sys_user table and can be provisioned in several ways — manually for one-offs, CSV import for bulk onboarding, or ideally through LDAP or SSO integration for automated provisioning and deprovisioning. Groups in sys_user_group serve multiple purposes: they're used for assignment routing, approval workflows, notification subscriptions, and importantly, role inheritance. My approach is to always assign roles at the group level rather than to individual users. It's much cleaner from an audit perspective, and when someone moves teams, you just change their group membership instead of hunting down individual role assignments. Groups can also be nested — child groups inherit the parent's roles, which maps well to organisational hierarchies.

Update sets are essentially a wrapper that captures all your configuration changes in a development instance. Say you have dev, test, and prod — you spin up an update set with proper naming conventions, select it as your current set, and any changes you make get recorded as customer updates. It's important to know that not everything is automatically captured — some form changes need to be manually added, and data changes aren't included at all, so you need to be aware of that. Once the developer is happy with their work and has done functional testing in dev, they promote the update set into the test instance for proper UAT. If the tester finds issues, the dev spins up an additional update set, makes the fixes, and promotes again. You can batch update sets together, but personally I prefer keeping them separate — it gives you a cleaner audit trail and makes it easier to back out specific changes if something goes wrong. Good hygiene is key: fill in all fields on the update set form, use consistent naming like "GEN-001 - Adding field to incident form," populate dates, and add descriptions. Only once UAT is passed should an update set ever be committed to production. And the beauty is, if something does go wrong, update sets can be backed out.

The itil role is the baseline for anyone who needs to work within ITSM modules — incident, problem, change, and so on. It grants access to fulfiller views and actions. The admin role is the most powerful — it bypasses most ACLs and gives unrestricted access to configure the platform. In practice, you want to limit who holds admin and for how long. Some orgs use time-boxed admin access or elevated custom roles for day-to-day work. snc_internal is a ServiceNow internal role — you wouldn't assign it, but you'll see it referenced in base system ACLs. The key principle is least privilege: give people exactly the access they need, nothing more. If someone only needs to manage catalog items, build a role for that rather than giving them itil or admin.

A UI Policy is client-side — I'd use it to control the form experience, like hiding or showing fields, or making something mandatory based on what a user selects. A Business Rule is server-side and runs on database operations. It gives me more control over data integrity — for example, I can use a 'before' rule to validate or transform data before it's saved, or an 'after' rule to trigger downstream actions like notifications. The way I think about it is: if I need to affect what the user sees on the form, it's a UI Policy. If I need to affect what happens to the actual data, it's a Business Rule. Worth noting — UI Policies do have a server-side checkbox, but it's generally discouraged because it can cause performance issues.

Both sit in the Service Catalog and look identical to the end user — they fill in a form and submit. The difference is what happens behind the scenes. A Catalog Item creates a Requested Item (RITM) and associated catalog tasks, following the standard request fulfilment model. It's designed for ordering things — a laptop, software access, a new hire setup. A Record Producer creates a record directly on a target table — like an incident or a change request. So if you want users to raise an incident through the portal without seeing the incident form, you'd use a Record Producer that writes to the incident table. The choice depends on whether you want the fulfilment workflow (Catalog Item) or a direct record creation (Record Producer).

There are a few ways to customize forms. Form Layout is the classic approach — you go to Configure → Form Layout and drag fields into sections and columns. It's quick and straightforward. Form Designer is the more modern version — it's visual, lets you see the form as you build it, and you can configure field properties like read-only or mandatory right there. Both achieve the same result. The key thing to understand is views — you can have multiple form layouts for the same table. So the itil view might show different fields than what a self-service user sees. When customizing, always double-check which view you're editing. And while form changes should be captured in your update set, it's good practice to verify, because not all form-level changes are automatically tracked.

Configuration is using the platform's built-in tools to tailor it to your needs — things like form layouts, UI policies, workflows, system properties. These are upgrade-safe because ServiceNow knows about them and can preserve them through upgrades. Customization means writing custom code or modifying out-of-the-box components — things like custom business rules, script includes, or modifying base system scripts. These can break during upgrades because ServiceNow might change the underlying code you've modified. My approach is always configure first. If the platform gives me a way to do it without code, I'll use that. I only move to scripting when there's no configuration option that meets the requirement. And when I do customize, I document it thoroughly so the team knows what's been changed and why.

The core ITSM modules are Incident, Problem, Change, and Request — and the power is in how they connect. Incident management is about restoring service as quickly as possible when something breaks. If you start seeing patterns — say the same incident keeps coming up — that's when you raise a Problem to investigate root cause. Once you've identified the fix, you raise a Change to implement it properly, with risk assessment and approvals. Requests are separate — they're for standard service needs like "I need access to this application" or "I need a new laptop." Those go through the Service Catalog and follow the request fulfilment process. The relationships matter too — incidents can be linked to problems, problems generate changes, and the CMDB ties it all together by showing what infrastructure is affected.

An incident is a symptom — something is broken or degraded and we need to restore service as fast as possible. A problem is the underlying cause. The classic example: ten users report they can't access email — that's ten incidents. The fact that the mail server ran out of disk space — that's the problem. You can apply a workaround to the incidents while the problem is being investigated. Once you identify root cause, you raise a change to fix it permanently. Not every incident needs a problem — you only raise one when there's a pattern, an unknown root cause, or a major incident that warrants deeper investigation.

Change management in ServiceNow supports three types. Standard changes are pre-approved and repeatable — things like scheduled maintenance or routine deployments that follow a known, low-risk process. Normal changes require proper assessment — you fill in the risk, impact, implementation plan, backout plan, and it goes through an approval flow, often a CAB or peer review. Emergency changes are for urgent fixes — something is broken in production and needs to be fixed immediately. The approval is expedited but still documented, and you do a proper review after the fact. Regardless of type, every change should answer: what are we doing, why, what's the risk, how do we test it, and how do we back it out if something goes wrong.

The CMDB is the Configuration Management Database — it's essentially a map of your IT infrastructure. It stores Configuration Items (CIs) — servers, applications, databases, network devices, business services — and crucially, the relationships between them. The real power isn't just knowing what you have, it's knowing how things connect. If a server goes down, the CMDB tells you which applications are affected, which business services are impacted, and who needs to be notified. It ties directly into ITSM processes: incidents are linked to affected CIs, changes reference what they're modifying, and problem management can use it to identify patterns across infrastructure. The catch is that a CMDB is only useful if it's accurate. Data quality is everything — so you need processes around discovery, reconciliation, and regular audits to keep it healthy.

Upgrades need a structured approach. First, I'd review the release notes to understand what's changing — new features, deprecations, and breaking changes. Then I'd clone production into a sub-production instance and run the upgrade there. After the upgrade, the critical step is reviewing skipped records — these are places where your customisations conflict with ServiceNow's updated versions. Each one needs a decision: take theirs, keep ours, or merge. I'd then run Instance Scan to check for best practice violations and any health issues introduced by the upgrade. From there, it's thorough UAT — testing critical workflows, integrations, scheduled jobs, and any custom scripts. Once the team is confident, you schedule the production upgrade during a maintenance window, execute it, validate, and monitor closely for the first few days.

Instance Scan is a built-in health check tool that evaluates your instance against ServiceNow's best practices. It scans for things like performance issues — say a business rule that's doing expensive queries — manageability concerns, potential upgrade risks, and security vulnerabilities. It produces a findings report where each issue is categorised by severity and comes with remediation guidance. I'd use it regularly as part of platform governance, not just before upgrades. You can also create custom scan checks if your organisation has specific standards. The findings should be triaged and tracked like any other work — assigned to someone, prioritised, and resolved.

Day-to-day, I'd keep an eye on a few key areas. System diagnostics — stats.do is a quick pulse check on node health, memory usage, active transactions, and semaphores. Scheduled jobs need monitoring for failures, long-running jobs that might indicate performance issues, and stuck jobs that need restarting. System logs and slow query logs help you spot trends before they become incidents. Email is another one — notifications are critical for workflows, so monitoring the email queue and outbound mail logs catches issues early. I'd also set up a dashboard that surfaces these metrics in one view so the team can see platform health at a glance without having to dig through individual modules.

Governance starts with process discipline. Every configuration change goes through proper change management — dev to test to prod, no exceptions. Update sets need proper naming conventions and descriptions, and nobody should be making real changes in the Default update set. Role and access governance is ongoing — regular audits of who has admin or elevated roles, removing access that's no longer needed, applying least privilege. Instance Scan should be run on a regular cadence with findings tracked like any other backlog item. Documentation is non-negotiable — every customisation should be documented with what was changed, why, when, and who did it. For Genesys specifically, with the team being new and distributed across three regions, building strong governance habits early will pay off massively as the platform matures. And the GDPR angle is important — with EU customer data, you need clear controls around who can access what, which is where ACLs, data policies, and having EU-based admins come into play.

Reports are built by selecting a table, applying filters, choosing a chart type, and grouping or trending the data. You can do bar charts, pie charts, trend lines, lists, and more. Dashboards collect multiple reports into a single view — you arrange them in a grid layout and can add different widget types. Reports can be scheduled for automated delivery — really useful for giving stakeholders a weekly summary without them having to log in. For more advanced needs, Performance Analytics lets you define KPIs and track them over time with indicators, breakdowns, and targets. The most important principle is intentionality — every report should help someone make a decision. If a dashboard doesn't drive action, it's just noise.

For a new deployment, I'd start with the reports that give the team immediate visibility. For incidents: open vs resolved over time, mean time to resolution, and breakdowns by priority, category, and assignment group — this tells you where the pain is. For changes: a trend of changes by type, success and failure rates, and a change calendar so teams know what's happening when. For requests: catalog item popularity helps you optimise what you offer, and fulfilment time shows where bottlenecks are. SLA attainment is critical — leadership will always want to know if you're meeting your service targets. And for platform health, I'd track scheduled job failures, update set activity, and user adoption metrics. I'd bundle these into role-specific dashboards — one for the ops team, one for management, and one for the platform admin team.