Schema comparison guide
Schema comparison guide
Schema Comparison Guide A side-by-side reference to help you choose the right schema for your environment.
LaunchPad ships thirteen service model templates, grouped into five categories: Foundation, Operational, Specialised, Enterprise, and Governance. The categories describe the job a schema 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
| Schema | 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-schema 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 schema estate | Schema documentation, validation, and release gates |
Most of these templates 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 schemas 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. 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 schemas
If you are not sure which schema 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 CMDB 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 schema 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 schema that sits alongside whichever Foundation schema 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 schema is stable.
Can I install more than one?
Yes. Each schema installs into its own Assets schema and does not affect anything else in your environment. Installing multiple schemas 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 schema, get it operational, then expand. Each schema requires ownership fields to be populated and relationships to be validated before it delivers its full value. Trying to operate three schemas at once before any of them are fully set up is a common reason teams lose momentum.