Schema comparison guide
Schema comparison guide
Schema Comparison Guide A side-by-side reference to help you choose the right schema for your environment.
JSM LaunchPad ships with thirteen service model templates. They are not a hierarchy where bigger means better. Each one addresses a specific operational domain, and 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 full catalogue at a glance
| Schema | Best suited for | Complexity | Key operational focus |
|---|---|---|---|
| Basic CMDB | First-time Assets users, small environments | Starter | Core service structure, foundational CI tracking |
| Core Schema | Internal IT operations, people and infrastructure focus | Operational | People, roles, infrastructure, and service dependencies |
| Service Catalogue | Request-driven teams, service desk maturity | Operational | Published services, SLAs, request types, ownership |
| Standard CMDB | Most organisations as a general-purpose model | Operational | Full service model with relationships, ownership, and change linkage |
| Enterprise IT CMDB | Large or complex environments, multi-domain IT | Enterprise | Business, application, compute, data, network, and security layers |
| Cloud-Native Infrastructure | Cloud-first teams (AWS, Azure, GCP) | Advanced | Platform and infrastructure mapping, cloud service dependencies |
| Workforce Management | HR-adjacent IT, onboarding, access lifecycle | Enterprise | People, skills, assets, access rights, organisational structure |
| Software Asset Management | Licence compliance, software lifecycle | Advanced | Licence records, contracts, discovery integration, compliance tracking |
| Vendor Management | Procurement, third-party risk, contract oversight | Enterprise | Vendors, contacts, contracts, SLAs, risk and performance |
| Cybersecurity | Security teams, vulnerability and risk management | Advanced | Assets, vulnerabilities, controls, compliance, scanner integration |
| Priority Matrix | Incident triage, SLA calibration | Operational | Impact and urgency mapping, priority calculation, team alignment |
| SLA Management | Service level definition and tracking | Operational | SLA objects, breach rules, service linkage, reporting foundation |
Choosing between the general-purpose schemas
If you are not sure which schema to start with, most teams fall into one of these four 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 manage a large, complex IT estate. Enterprise IT CMDB is built for environments where the business layer, application layer, and infrastructure layer are all significant and need to be tracked separately. Do not start here unless you have the operational capacity to maintain it.
Your services live primarily in cloud platforms. Cloud-Native Infrastructure models the platform and infrastructure layer across AWS, Azure, and GCP. It works well alongside Standard CMDB or Enterprise IT CMDB, mapping the infrastructure picture to the service layer above it.
Choosing a specialist schema
The specialist schemas are not replacements for a general-purpose model. They address a domain that sits alongside your core CMDB and connects to it.
Workforce Management is for organisations where IT and HR processes intersect: onboarding, offboarding, access provisioning, and asset assignment. It complements Standard CMDB by adding the people and organisational layer.
Software Asset Management is for licence management and compliance. If your organisation runs periodic software audits or needs to demonstrate licence compliance, this schema provides the structure to track software assets, contracts, and usage across your estate.
Vendor Management covers third-party relationships: suppliers, contracts, SLAs, and risk assessments. It connects to your service model by linking services to the vendors that underpin them.
Cybersecurity gives security teams the structure to track assets alongside their vulnerability and risk status. It is designed to integrate with scanning tools and feeds into compliance and audit workflows.
Priority Matrix and SLA Management are operational frameworks rather than inventory schemas. Priority Matrix structures how you calculate and assign incident priority. SLA Management defines and tracks your service level commitments. Both integrate tightly with incident and request handling in Jira Service Management.
Can I install more than one?
Yes. Each schema installs into its own isolated 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.
A common combination is Standard CMDB as the core, 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.