ServiceNow Common Service Data Model Requirements Workshop Questions

This page helps a program team decide what the Common Service Data Model should contain before any configuration starts. It sets out the questions on service scope, ownership, attributes, integration and rollout, the decisions each answer commits the program to, and the answers that should stop a workshop until the missing facts are found.

Service Scope and Definition Questions

These questions establish what you consider a service and what scope the service model will cover.

What counts as a service in your organization? Just customer-facing applications? Internal services too? Does IT itself count as a service, or just what IT provides? Defining scope prevents confusion about whether something is in or out of scope.

Will you have business services, technical services, or both? Business services represent what you deliver to customers or users. Technical services represent infrastructure and applications that support business services. Both? Just technical? This choice affects the entire structure.

How many services do you expect to define? Hundreds? Thousands? A service model with too many services becomes hard to maintain. Too few services hides important details. Most organizations find 50-200 services is manageable.

Service Ownership and Governance Questions

These questions establish who owns services and how they are governed.

Who will own each service? Is there one owner per service, or can services have co-owners? If a service is jointly supported by multiple teams, who is the primary owner for decisions? Clarity prevents disputes.

How will services be updated? Can any team update their service data, or must changes go through a governance process? If anyone can change service data, consistency suffers. If changes require approval, governance slows things down. Balance is needed.

Who will review and approve the initial service model? Service owners? Leadership? Before activating CSDM, someone needs to review and confirm the service structure is correct.

Attribute and Relationship Questions

These questions establish what information you track about services and how services relate.

What attributes does each service need? Name, owner, cost center, description, category, and then what? Customer-facing? Business criticality? Change frequency? Define attributes that help you make decisions or comply with policies.

What relationships between services matter? Does a service depend on other services? Does it support other services? Is it part of a larger capability? Define relationships that help you understand impact.

How will you handle service relationships that are bidirectional or complex? If Service A depends on Service B, does the relationship automatically show that Service B supports Service A? If Service C depends on both A and B, does the model handle that complexity? ServiceNow can handle complex relationships, but make sure the model is clear enough for people to understand.

Integration and Reporting Questions

These questions establish how service data will be used in other modules.

Which modules will use the service model? Incident Management? Service Mapping? Financial Management? Each module uses service data differently. Define which modules will rely on the model.

What reports do you need from the service model? Service inventory? Service health? Services by owner? Services by business criticality? Define reports that help you make decisions. Use reports to drive the service attributes and structure.

How will you handle services that are defined in other systems? If you have a separate application portfolio, will services there be imported to CSDM or kept separate? Decide on integration points early.

Phasing and Rollout Questions

These questions establish how you will implement the service model.

Will you activate CSDM at once for all services or gradually? Starting with a pilot set of services (maybe the top 10 most critical) lets you validate the model before full rollout. Full rollout at once is faster but more risky.

How will you migrate existing service definitions to CSDM? Do you already have services defined in Service Mapping or other modules? How will those be mapped to CSDM? Plan migration carefully.

Warning Signs

If stakeholders disagree on what counts as a service, that disagreement needs to be resolved before implementation. If service owners do not want to maintain service data, the model will go stale. If no one can articulate the business value of the service model, it will be hard to get buy-in for the work required to implement it.

What a Requirements Workshop Has to Settle

A requirements session for CSDM earns its time only when it finishes with a short, written list of decisions. The risk is a session that generates many open questions and a feeling of progress. To avoid that, treat every question as belonging to one of three outcomes: a decision the room can make now, a decision that needs a named person outside the room, or a fact that someone must go and find. Anything that cannot be placed in one of those three buckets is probably two questions merged together, and should be split before it is discussed.

The facilitator’s first job is to agree the purpose of the model out loud. Ask the room which operational decisions the service model must support in the first year. Incident triage, change risk review, cost allocation, and audit evidence each need a different level of detail. A model built for audit evidence records ownership and control links. A model built for triage needs dependency depth. Both can coexist, but the workshop must say which one wins when they conflict.

Decision Points and What Each Answer Commits You To

The table below lists the questions that often decide the shape of the model. For each one, the right-hand columns show what the answer commits the program to. Put the table on the wall during the session and fill in the consequences as the group talks.

Running the Session in Order

1. Open with the three operational decisions the model must support, and write them on the first sheet. Everything later is checked against that sheet.
2. Walk the decision table one row at a time. Do not move on until the room has either decided or named the person who will decide.
3. Ask each participant to name one service they believe is missing from the draft list. Record the names, then ask the owner of the most likely neighboring service to confirm or reject each one.
4. Take the attribute question last. Attributes are easy to add and hard to remove, so agree the minimum set that supports the decisions on the first sheet, and park the rest. Attributes that carry access implications should be checked against the security and access design before they are agreed.
5. Close by reading back every decision and every open item with its owner. A decision the group did not hear read back is often reopened later.

Answers That Should Stop the Session

Some answers mean the workshop cannot produce a usable model yet, whatever the time remaining. If two departments each claim ownership of the same customer-facing service and neither will give way, stop. If nobody in the room knows which servers a flagship service runs on, stop and schedule a fact-finding session with the infrastructure lead. If the group wants the model to replace an existing report without first agreeing what that report is for, stop and go back to the purpose sheet. Continuing in these conditions can produce a model that looks complete and gets argued over for months.

Preparing Participants Before the Room

Send the purpose sheet and the decision table in advance, and ask each attendee to bring their current service list, even if it is incomplete. Attendees who arrive with a list often argue about specific services. Attendees who arrive without one often argue about definitions in the abstract, which takes far longer to resolve. For the maintainer role, see the CMDB ownership model post.

Frequently Asked Questions About CSDM Workshop Preparation

Who should attend a CSDM requirements workshop?

Include a person who can decide on service definitions, a person who knows the infrastructure, a person who runs operations, and the person who keeps the records current afterwards. A workshop without the maintainer often produces a model that the maintainer cannot keep current. The roles and RACI guide helps decide who that person is.

How many sessions does the work normally need?

Many groups need more than one. A common pattern is one session on purpose and scope, a second on relationships and ownership, and a third to review the draft service list with the owners who were not in the earlier rooms. The number depends on how many owners are involved and how much disagreement there is.

What if the business and IT describe services differently?

Record both descriptions, and agree which one the model will use as the primary record. The other can be kept as an alias or a note. Forcing agreement in the room often hides a real difference that will reappear as a report disagreement later.

Should the workshop agree the reporting requirements?

Agree the list of reports that the first release must produce, and leave the rest for later. Reporting requirements written before the model exists can ask for fields the model cannot yet support.

Next Step After the Workshop

The most useful feedback often concerns the decisions that were parked, because those are where scope can grow after go-live. The requirements workshop decisions post is the decision-log view of the same session.