CSDM is the blueprint ServiceNow gives you for organizing your data so that one word — “service” — means the same thing everywhere. This page assumes you know nothing about ServiceNow. We'll build it up from the ground with pictures, analogies, and real scenarios.
Before CSDM makes any sense, you need six pieces of vocabulary. None of them are complicated — they just have intimidating names.
Imagine a single, enormous catalog that lists every single thing your IT department runs: every server, laptop, database, network switch, and application. That catalog is the CMDB (Configuration Management Database). It's the shared source of truth that all the other tools look at.
Each individual thing in the catalog is a Configuration Item, or CI. One server is a CI. One database is a CI. One application is a CI. If the CMDB is the catalog, a CI is a single line in it — one record.
Things of the same kind are stored together in a table — think of a tab in a giant spreadsheet. There's a table for servers, a table for databases, and so on. The technical name for “a kind of CI” is a class. So “Windows Server” is a class, and it lives in its own table. You'll see table names like cmdb_ci_server — that's just the spreadsheet-tab name.
Nobody wants to type thousands of servers in by hand. Discovery is an automated tool that scans your network and fills the catalog for you. Service Mapping goes a step further: it figures out how things connect — which app depends on which database on which server — and draws that map automatically.
ServiceNow isn't one app; it's a platform with many. They all read from the same CMDB:
If ten people each fill the catalog their own way, nothing lines up. The help desk calls something “Payroll App,” operations calls it “WD-PROD-02,” and finance calls it “Workday.” No tool can connect them. CSDM is the agreed-upon blueprint that says: here's exactly which table each type of thing goes in, and here's how they link together. It is not a plugin you install — it's a set of rules you follow.
This is the concept people trip over. A single service looks like a different thing depending on who's looking at it — and CSDM's whole job is to keep those faces linked. Forget IT for a second and think about a car.
“A Toyota Camry” is a concept — a model in a brochure. It doesn't have a specific licence plate; it's the idea of the car.
Your specific Camry in the driveway, licence plate ABCD-123, with 40,000 km on it — that's a real, running instance. When it breaks down, this is the one the mechanic actually works on.
The lease deal you signed — 36 months, 20,000 km/year, roadside assistance, $299/month — that's the packaged offer with its promises and price.
Those three are all “the Camry,” but they're genuinely different records for different audiences: the brochure/catalog team, the mechanic, and the salesperson. Nobody's confused, because everyday life keeps them separate.
CSDM does exactly the same thing for IT services. Map the car onto payroll:
Hold that trio in your head — concept, running instance, packaged promise — and the rest of CSDM falls into place.
Here is the heart of CSDM. Read it as two columns. The left is the delivery story — how a service is built and actually runs, from a fuzzy business idea down to real servers. The right is the consumption story — how that same service is packaged and sold to the people who use it. A single relationship bridges them.
Notice you're moving from abstract to concrete. At the top, a business capability is just a job the business needs done — “getting people paid.” It doesn't care which tool you use; it would exist even if you switched from Workday to something else. Next, the business application is the actual app you funded to do that job — “Workday.” It's one record no matter how many copies you're running, and it's the thing your architecture team tracks. Below that, the application service is a specific running copy — “Workday – production” — the one Discovery finds and hangs real servers and databases underneath. At the bottom sit those infrastructure CIs: the metal it runs on.
The business service is the service as the people using it think of it — “employee payroll.” The service offering is a specific, committed package of that service: “payroll, guaranteed within 24 hours, supported around the clock.” One business service can have several offerings (a “standard” one and a “VIP, faster” one) — just like one product can be sold in different tiers.
A monitoring alert fires on a database server. Because Discovery mapped that database under the “Workday – production” application service, and because that application service is what delivers the “Payroll – 24/7” offering, ServiceNow can instantly answer the only question that matters to a manager: “which business service is now at risk, and who does it affect?” Without CSDM's bridge, that database is just an anonymous box and nobody connects it to payroll until people start complaining.
CSDM sorts every record into one of seven domains — think of them as neighborhoods. One neighborhood, Foundation, sits underneath all the others and supplies shared basics. The rest form the life-story of a service, left to right: an idea becomes a design, gets built, is delivered as something running, and is finally consumed by the business.
Look back at the service model in section 03 and you'll see it living inside these domains: business capability and business application are Design & Planning; the application service and its infrastructure are Service Delivery; the business service and service offering are Service Consumption. Same records — the domains are just the neighborhoods they live in.
Every concept above is stored in a specific out-of-box table. You don't invent these — CSDM tells you which one to use. The names look scary but they're just spreadsheet-tab labels. (The cmdb_ci_ prefix simply means “a CI in the CMDB.”)
| Concept | Table | In plain English |
|---|---|---|
| Business capability | cmdb_ci_business_capability | A job the business does, tool-agnostic. |
| Business application | cmdb_ci_business_app | The funded app itself — one record, tracked in the app portfolio. |
| Application service | cmdb_ci_service_auto | A running, deployed copy — the one Discovery/Service Mapping fills in. |
| Business service | cmdb_ci_service_business | The service as the customer experiences it. |
| Service offering | service_offering | A committed package of that service: SLA, hours, price. (Note: no cmdb_ci_ prefix.) |
| Base service class | cmdb_ci_service | The parent all service classes above inherit from. |
If you remember just one structural fact: every kind of service — business, application, and so on — is ultimately a specialized child of cmdb_ci_service. The service_offering table is the odd one out, because an offering is a commercial package, not a technical CI.
Nobody builds all of CSDM at once. ServiceNow describes a four-stage climb. Each stage populates a bit more of the model and, in return, unlocks new abilities. You don't skip steps — a wobbly Foundation ruins everything built on top of it.
Crawl: the help desk can finally route a ticket to the right team because every user, group, and location is clean. Walk: operations gets an alert and instantly sees the three business services that server touches. Run: the service owner can say “payroll is a 99.9%, 24/7 commitment” and report against it. Fly: leadership looks at a roadmap and retires two overlapping apps because the portfolio data finally shows the overlap. Each stage is worthless without the one before it.
A common exam phrasing is the rollout order — just remember the climb always starts at Foundation and you never build offerings (Run) before the technical services (Walk) that deliver them.
If CIS-DF is testing one thing, it's this. People collapse these two into a single record, and it quietly corrupts the whole model. They are the same app — but two different records, for two different audiences.
Business application = the funded, logical concept. One record. It's what the business names, owns, and pays for, and it's tracked in Application Portfolio Management (APM). Think: the “Camry” in the brochure.
Application service = a specific running deployment — production, test, dev. There can be several. It's populated by Discovery, and it's where operations attaches the real servers, alerts, and impact. Think: your actual car in the driveway.
Why does the split matter so much? Because the two records serve people who care about completely different things. Your architecture and finance teams ask “how many apps do we own, what do they cost, which overlap?” — they live in the business-application record. Your operations team asks “is production up, and what breaks if this server dies?” — they live in the application-service record. Mash them into one and neither team can answer their question.
Suppose you model “Workday” as a single record and point both the app-portfolio report and Discovery at it. Now you run Workday in three environments. Do you create three “Workday” records? Then your portfolio thinks you own three apps and your costs triple on paper. Or one? Then operations can't tell which environment an alert came from. The clean answer is CSDM's answer: one business application (Workday) and three application services (prod, test, dev) linked to it.
Let's model something you're now holding: ServiceNow and its ITSM module. It's a great test because ServiceNow is SaaS (software you rent, running on the vendor's servers), which is exactly where people mis-model.
| Layer | Record for ServiceNow ITSM | Why |
|---|---|---|
| Business capability | IT service management | The job: running a help desk. True even if you swapped tools. |
| Business application | ServiceNow ITSM | The funded app you own, tracked in APM. (One record.) |
| Application service | ServiceNow ITSM – prod | Your live instance. Test/dev would be siblings. |
| Infrastructure (SaaS = thin) | the instance + MID Server | The datacenter is the vendor's — you don't own those servers, so don't invent them. |
| Business service | IT service desk | How employees experience it. |
| Service offering | IT support – 24/7 | The committed package, with response times. |
| Foundation | ServiceNow Inc. = Company; subscription = Contract | The vendor and the deal are shared basics everything references. |
For on-premise software you'd map a deep tree of servers and databases under the application service. For SaaS like ServiceNow, that tree is thin: the servers belong to the vendor and live in their CMDB, not yours. You model the instance, your MID Server, and integration points — and you resist the urge to invent infrastructure you don't own. The application service is still real and important; it just doesn't have much hanging beneath it.
One judgment call worth knowing: if your organization funds ITSM, ITOM, HRSD, and so on separately, model each as its own business application. If you treat “ServiceNow” as one funded platform, model it as a single parent business application that the modules depend on. Either is defensible — the rule is to model at the level the business actually manages and pays for.
This page is the companion to your CIS-DF deck. Every concept here — the service model, the seven domains, the maturity climb, and the business-application-vs-application-service trap — is now in the flashcards.
Open the flashcards →