ServiceNow CIS-CSM common mistakes
ServiceNow CIS-CSM · Understand the traps and how to avoid them.
Answering case lifecycle questions with ITSM vocabulary - saying a customer issue is logged as an Incident and escalated to a Problem, or describing CSM case states as New/In Progress/On Hold/Resolved/Closed exactly as an Incident's.
Most candidates come from an ITSM background and the two products share the task table, the navigation shell and much of the terminology, so the brain auto-fills the familiar incident model without checking whether the question is asking about sn_customerservice_case.
What to do instead
Before answering, ask 'which table is this?' Cases live on their own table with their own state model, case types and resolution codes; case work is broken down with Case Tasks and Child Cases, not with Problem/Change tasks. Drill the case state list and case type field until they are as automatic as incident states.
Treating Entitlements and Service Contracts as niche advanced configuration and answering eligibility questions as if any contact can always raise any case and always receive the same SLA.
In demo instances everything works because no entitlement gating is configured, so the candidate never sees the behaviour the exam is testing and assumes it does not exist.
What to do instead
Learn the entitlement chain explicitly: Account → Service Contract → Entitlement (with support level, covered products, and validity dates) → whether a case can be created and what support terms apply. Practise explaining what happens when a contact with no valid entitlement tries to submit a case.
Modelling every customer as an Account - creating one Account per individual person - or using Contact and Consumer as if they were unrelated record types with no relationship to an Account.
Candidates carry over the single 'user' concept from ITSM, where a person is just a sys_user, and never internalise that CSM separates the organisation, the people at that organisation, and the relationships between them.
What to do instead
Memorise the three layers and the direction of the relationships: Account is the organisation, Contact is a person, and contacts link to accounts through relationship records - so one contact can legitimately belong to several accounts. Be able to state which record holds the billing/support address versus which holds the individual's details.
Using Case, Child Case and Case Task interchangeably - for example answering that a multi-part customer request is handled by creating Case Tasks for each department, or that a subtask can carry its own SLA and be resolved independently of the parent.
All three appear under a case in the related lists and all three look like 'work items', so the distinction is glossed over during skim-reading of the docs.
What to do instead
Write out one line each: a Case is the customer-facing record; a Child Case is a separate case linked to a parent (its own number, own assignment, own SLA); a Case Task is internal work inside one case and is not customer-facing. Then test yourself on which one appears in the customer portal.
Assuming a case can be moved to Closed from any state, or that resolution is just a free-text note with no required fields.
The state field looks like a simple choice list and the candidate reasons from generic ticketing tools rather than from the CSM state-transition rules and resolution code requirements.
What to do instead
Learn the case state model as transitions, not a list, and learn that closure requires a resolution (code plus notes) and typically a prior Resolved state. Practise the sequence: what must be populated before Resolved, and what still must be populated before Closed.
Assuming that form layouts, UI policies and client scripts alone determine how a case form behaves in the CSM Configurable Workspace, and answering 'create a UI policy' for any workspace behaviour question.
Decades of classic-platform habit make the form the default mental model; the candidate has not separated the platform record configuration from the workspace presentation layer.
What to do instead
Draw the split clearly: table-level configuration (dictionary, UI policies, business rules, ACLs) applies everywhere, but what the agent actually sees is driven by UI Builder pages, page variants, and workspace record-page configuration. For any 'how does it look/behave for the agent' question, ask first whether it is data-level or presentation-level.
Conflating the portals - answering that the agent workspace is a Service Portal page, or that the Customer Service Portal, the consumer-facing portal and the employee portal are the same artifact with a different theme.
Service Portal was the historic answer to every portal question and the product now offers several distinct portal experiences, so candidates collapse them into one mental bucket.
What to do instead
Maintain a small table in your notes: each portal's audience (agent vs external customer vs employee), its underlying technology, and what it is used for. Then practise the question 'who is the user standing in front of this screen?' - that single question resolves most portal items.
Assuming Advanced Work Assignment is enabled by default, or conversely that cases are always routed by assignment rules on the case table, without being able to name the pieces that make AWA work.
AWA is invisible when it has not been configured - cases just sit unassigned - so the candidate never observes the mechanism and guesses at how assignment happens.
What to do instead
Learn the AWA chain end to end: service channel (what work is being routed, defined by a condition) → assignment eligibility/queues → agent capacity and availability → assignment. Know that it must be set up per service channel and that a case only enters routing if it matches a channel condition.
Assuming remote tables are two-way integrations, or that any external system integration must be built as a custom SOAP/REST call from scratch.
Remote tables look like ordinary tables in a list view, so the read-only constraint is easy to miss, and ready-made connector options are less well known than hand-built scripted integrations.
What to do instead
State the rule plainly: remote tables surface external data read-only through a data source; writes to the external system need an outbound integration (Flow Designer action, scripted REST, or a connector). Also learn which packaged third-party connectors exist for common CRM back ends so you can pick the supported option over a custom build.
Assuming Performance Analytics is available in every CSM instance, or answering reporting questions with 'build a report on the task table' when the question is about case trend and backlog analysis.
Reporting and dashboards are learned as one undifferentiated topic, and the candidate does not check which table the data should come from or whether indicators are part of the licensed product.
What to do instead
Separate operational reporting (reports and dashboards on the case table) from analytical reporting (indicators, indicator sources, breakdowns, and the data collection jobs that populate them). For each reporting question, name the table or indicator source first, then the visualisation - and check the licensing/plugin assumption before committing to an answer.