Service model comparison guide
Service model comparison guide
Service model comparison A side-by-side reference to help you choose the right service model for your environment.
LaunchPad ships thirteen service models, grouped into five categories: Foundation, Operational, Specialised, Enterprise, and Governance. The categories describe the job a service model does, nothing more. They are not a maturity ladder and they are not price bands; pricing is per object across the whole product regardless of category. The right choice depends on what your team actually needs to manage, not how large or mature your organisation is.
This page gives you the comparison in one place.
The available catalogue at a glance
| Service model | Category | Types | Version | Best suited for | Key operational focus |
|---|---|---|---|---|---|
| Basic CMDB | Foundation | 2 | v2.0 | First-time Assets users, small environments | A deliberately minimal starting point for learning Assets |
| Core Schema | Foundation | 8 | v1.2 | Every multi-model environment; the shared hub | Master data: people, teams, vendors, cost centres, business services |
| Standard CMDB | Foundation | 8 | v3.0 | Most organisations as a general-purpose model | Services, applications, and infrastructure with ownership and dependencies |
| Workforce Management | Foundation | 9 | v3.2 | Organisations whose first problem is people, not servers | Roles, skills, assignments, and asset access built around Core people data |
| Service Catalogue | Operational | 6 | v2.0 | Request-driven teams, service desk maturity | Published services, offerings, request types, ownership |
| Priority Matrix | Operational | 4 | Incident triage, SLA calibration | Impact and urgency mapping, priority calculation, team alignment | |
| SLA Management | Operational | 3 | v1.1 | Teams formalising service level commitments | Service level definition, targets, and tracking |
| Cloud-Native Infrastructure | Specialised | 10 | v1.1 | Cloud-first estates on AWS, Azure, or GCP | Accounts, clusters, namespaces, deployments, and the services around them |
| Cybersecurity | Specialised | 5 | v1.1 | Security teams tracking exposure and compliance | Assets, vulnerabilities, controls, and compliance posture |
| Software Asset Management | Specialised | 8 | v2.0 | Licence and software lifecycle owners | Products, agreements, entitlements, and installations |
| Enterprise IT CMDB | Enterprise | 20 | v2.0 | Large estates spanning many domains | Cross-domain CMDB from business layer to network |
| Vendor Management | Enterprise | 11 | v2.0 | Organisations with serious third-party oversight needs | Contracts, risk, performance, spend, and issues around Core vendor records |
| Documentation Management | Governance | 7 | v1.2 | Teams governing their service model estate | Service model documentation, validation, and release gates |
Most of these service models are spokes on the Core hub: they cover their own domain in depth and refer back to Core Schema for shared master data such as people, teams, and cost centres. Where two models look like they overlap, the overlap is usually a shared reference into Core rather than duplicated types, and at deploy time you decide how each reference resolves: link to the existing Core object, create the type locally, or keep plain text. References are not fixed at install: object types and reference types stay editable after deployment, and you extend a model later with Expand a Service Model. See Hub-and-spoke architecture and The three reference modes.
A note on the Foundation grouping: Core Schema is the foundation proper, the hub that holds the master data the rest of the catalogue refers to. Standard CMDB and Workforce Management share the category label because either one can serve as a starting foundation if you deploy it on its own and create people locally with the Create here option, but where you have a choice, build on Core.
Choosing between the general-purpose models
If you are not sure which service model to start with, most teams fall into one of these situations:
You are new to Assets. Start with Basic CMDB. It is intentionally minimal, which makes it easy to learn from. Once you understand how object types, relationships, and ownership work in practice, expanding to a fuller model is straightforward.
You need a working service model quickly. Standard CMDB is the default for most organisations. It covers service ownership, application dependencies, infrastructure relationships, and change linkage without adding layers you are not ready to operate.
You need the organisational backbone in place first. Core Schema establishes people, teams, departments, locations, vendors, and cost centres. Useful when those entities need to exist before you stand up the service model on top of them.
You are service-desk driven. Service Catalogue is built around published services, support teams, and request types, giving you the structure to tie incoming tickets to the services they relate to.
Your starting problem is people, not infrastructure. Workforce Management models roles, skills, assignments, and asset access on top of the people data in Core, which makes it a legitimate first service model for HR-adjacent and resourcing-driven teams.
Adding Priority Matrix alongside
Priority Matrix is not a replacement for a general-purpose model. It is a small, focused service model that sits alongside whichever Foundation model you pick and structures how you calculate and assign incident priority using impact and urgency mapping. It integrates tightly with incident handling in Jira Service Management. Deploy it after your starter model is stable.
Can I install more than one?
Yes. Each service model installs into its own Assets object schema and does not affect anything else in your environment. Installing multiple models is the expected pattern for organisations with more than one operational domain to manage, and the hub-and-spoke design means they share Core master data instead of duplicating it.
A common combination is Core Schema plus Standard CMDB as the base, with Vendor Management added for third-party oversight and either Software Asset Management or Cloud-Native Infrastructure added depending on the dominant infrastructure pattern.
Pro tip: Install one service model, get it operational, then expand. Each model needs ownership fields populated and relationships validated before it delivers its full value, and you can grow it in place afterwards with Expand a Service Model. Trying to operate three models at once before any of them are fully set up is a common reason teams lose momentum.