ServiceNow CIS-ITSM common mistakes
ServiceNow CIS-ITSM · Understand the traps and how to avoid them.
Classifying every ticket as an incident (or every ticket as a request) because the user 'asked for something'; for example logging a broken laptop as a catalog request, or logging a new-monitor request as an incident.
Both record types land in the same service desk queue and both can carry approvals and tasks, so candidates answer from the user's phrasing instead of from the definition of a failure of an expected service.
What to do instead
Apply the 'worked-before' test on every scenario: if the user expects a service that should already be delivered and it is degraded or unavailable, it is an incident; if the user wants something new or a standard fulfilment, it is a request/catalog item. Practise sorting 20 mixed tickets into the two buckets before touching the state models.
Describing incident handling without the concrete state and hold-reason mechanics: not knowing that On Hold requires a hold reason, that Resolve requires a resolution code, or that a reopened incident returns to In Progress rather than to New.
Candidates study the process flow diagram ('detect, log, resolve') but never memorise the base-system state list and its mandatory fields, so scenario questions about 'what happens when...' are answered by intuition.
What to do instead
Memorise the base incident state set (New, In Progress, On Hold, Resolved, Closed, Canceled) together with what each transition requires: hold reason for On Hold, resolution code for Resolved, close code optional at Closed, and reopen moving the record back to In Progress. Write the transition table from memory once a day until it is exact.
Assuming a major incident is a separate module or table, or that it is created automatically when priority becomes 1, and then choosing 'create a problem' or 'open a separate major incident record type' as the first action in a severity-1 scenario.
Major incident management looks like a distinct product area because it has its own workbench and communications tooling, which obscures the fact that the underlying record is still an incident.
What to do instead
Learn that a major incident is an incident record that is flagged/promoted as major and managed through the major incident workbench, and that promoting it does not replace the incident lifecycle. In any severity-1 scenario, the answer starts with promoting and managing the incident, with problem and change records linking to it afterwards.
Treating problem closure, known error, and the fix as one step: stating that a problem can only be closed once a permanent fix is deployed, or that creating a problem automatically raises the change that fixes the root cause.
ITIL wording ('problem management eliminates the root cause') reads as a single linear flow, so candidates collapse known error, workaround, and change into one activity.
What to do instead
Separate the three artefacts explicitly: a problem can move to Known Error once root cause is documented, a workaround can be published and the problem left open, and the permanent fix is delivered by a change request that is linked to the problem rather than created by it. On any scenario question ask 'which artefact is being asked about - problem, known error, or change?' before answering.
Answering change scenarios with 'it goes to the CAB' regardless of change type, or treating emergency as the only alternative to normal, and confusing change type with change model.
CAB is the most memorable part of change management, so it becomes the default answer; type versus model is an easy distinction to miss because both appear on the same form area.
What to do instead
Anchor on the three types and their authorisation: standard changes are pre-authorised and never go to CAB, normal changes follow their change model's approvals (which may or may not include CAB), and emergency changes go through the emergency authorisation path. Then treat change models as the records that define which type uses which approvals and workflow.
Assuming a published knowledge article is visible to everyone who can search, or that a Draft article is searchable by end users; also assuming all articles publish without approval.
Search results look global in demo instances, and approval workflow on knowledge is optional and configurable, so behaviour varies by instance and candidates over-generalise one demo.
What to do instead
Learn the two controls separately: lifecycle state (Draft/In Review/Published/Retired) determines whether an article is live, and user criteria (can read / cannot read) determines who can see a live article. Note that an approval step exists only when the article workflow is enabled, and answer visibility questions by naming both the state and the user criteria.
Collapsing the catalog record chain: calling the request the thing the user ordered, or expecting a catalog item to write directly to the requested item's fields without a flow or workflow.
The portal shows one 'request' to the user, hiding the three underlying records, and variables look like ordinary fields so candidates assume they propagate automatically.
What to do instead
Draw the three-level chain on scratch paper: request (one per order or order guide submission) contains requested items (the individual catalog items with their variables and approvals), which contain catalog tasks for fulfilment. Add that record producers create records in other tables (such as an incident) instead of a request, and that a flow or workflow, not the item itself, generates the tasks.
Treating the CMDB as a flat list of assets where any CI can be related to any other CI, and ignoring identification and reconciliation when asked how discovery populates the CMDB.
Asset-style thinking carries over from hardware inventory tools, and the CMDB class hierarchy plus IRE is the least visible part of the product to anyone who has not administered it.
What to do instead
Memorise that every CI lives in a table-per-class hierarchy under the base CI table, that CI-to-CI links are stored as relationships with a relationship type, and that discovery and other data sources populate and de-duplicate CIs through the identification and reconciliation engine governed by identification, reconciliation, and data-source precedence rules.
Confusing an SLA definition with the task SLA, or missing pause and stop conditions: assuming a task SLA is created the moment a task is opened and that it always runs on wall-clock time.
The definition is what candidates configure in the demo, so the runtime records it generates get little attention, and schedule and pause logic is easy to skip on a form with many tabs.
What to do instead
Separate design-time from run-time: the SLA definition holds the start, pause, stop, and reset conditions plus the schedule and workflow, and task SLA records are created only when a task meets the start condition and are then paused, stopped, or reset by those conditions. Always ask which of the two records a question is about, and check whether the schedule is a business schedule or 24x7.
Naming the wrong platform mechanism for a required behaviour, for example saying a UI policy enforces a field rule that must hold for API and import writes, or saying a business rule is the right place to hide a form field.
All four mechanisms (client script, UI policy, business rule, ACL) can look like 'make the field behave', and exam scenarios describe outcomes rather than the layer, so candidates pick whichever term they saw most recently.
What to do instead
Route every scenario through a layer question: does it happen in the browser only (client script/UI policy) or must it hold for every write path (business rule), and is it authorization (ACL)? Then state the mechanism plus why the other candidate mechanisms fail that test.