Core schema - quick start guide

Every domain schema in JSM LaunchPad needs to know who your people are, which teams they belong to, where they work, and which vendors supply your tools. The Core Schema provides that shared foundation. Deploy it once, and every other schema you add will reference it rather than maintaining its own duplicate copies of organisational data.

This guide covers all seven object types, their attributes, implementation best practices, and the import sequence that gets your data loaded cleanly on the first attempt.

---

When to use this schema

The Core Schema is the foundational master data layer that all other JSM LaunchPad schemas reference. Deploy it in these scenarios:

Starting your CMDB journey: You need a shared data foundation for people, teams, vendors, applications, and locations before deploying any domain-specific schema.

Multi-schema environments: You plan to deploy two or more domain schemas (e.g., Cloud-Native + Cybersecurity) and need a single source of truth for organisational data.

Lightweight asset tracking: You need basic application and vendor tracking without the complexity of a full Standard CMDB or Enterprise IT schema.

Cross-schema reporting: You want to query "which teams own which resources" or "which vendors supply which applications" across your entire CMDB ecosystem.

warning

⚠️ Not quite right? If you need a standalone CMDB with servers, databases, and network devices, use the Standard CMDB. If you need the simplest possible starting point with just 3 object types, use the Basic CMDB. Each paid schema can operate independently, though the Core Schema is recommended as a companion.

---

Deploy the schema

1. Open JSM LaunchPad from the Apps menu in your Jira navigation bar.
2. Select Core Schema from the template gallery. It sits in the Foundation category.
3. On the configuration screen, set the schema name and schema key. The default name ("Core Schema") works for most teams; change it if you need to distinguish between multiple organisational data schemas (for example, one per business unit or region). The schema key is the short prefix that appears at the start of every object key in Assets (e.g., CORE-1, CORE-2). You can set this to whatever makes sense for your organisation's naming conventions.
4. Click Deploy.

LaunchPad creates everything for you: 7 object types, 14 reference types, all attributes pre-configured with the correct types and allowed values.

---

Schema architecture

The single source of truth principle

The Core Schema implements a fundamental CMDB design principle: master data should exist in exactly one place. Instead of each domain schema maintaining its own copies of Person, Team, or Vendor records, they all reference the Core Schema.

No duplicate maintenance: Update a person's job title once, and it reflects everywhere. Cross-schema references: Other schemas can reference Core objects directly, so ownership and organisational context flow through without duplication. Note that AQL queries run within a single schema's context, so cross-schema reporting requires querying each schema individually or using the REST API. Referential integrity: Relationships remain consistent as data changes. Simplified auditing: One location to verify data accuracy.

Object type summary

Object Type	Purpose	Key Relationships
Person	Employees, contractors, external contacts	Reports To (Person), Member Of (Department), Works At (Location)
Team	Functional work units that own assets	Led By (Person), Part Of (Department)
Department	Organisational hierarchy from HR	Headed By (Person), Funded By (Cost Center), Parent (Department)
Location	Offices, data centres, remote regions	Parent (Location)
Vendor	External suppliers and partners	Relationship Owner (Person)
Application	Software used by the organisation	Owned By (Person), Managed By (Team), Provides (Vendor), Used By (Team), Depends On (Application)
Cost Center	Financial units for budget tracking	Owned By (Person)

Screenshot coming soon

Reference types

The Core Schema defines 14 custom reference types with colour-coded categories:

Colour	Category	Reference Types
Purple	Organisational hierarchy	Reports To, Member Of, Part Of, Parent, Funded By
Green	Service delivery	Works At, Provides, Used By
Blue	Ownership and accountability	Led By, Headed By, Owned By, Managed By, Relationship Owner
Orange	Technical dependencies	Depends On

Import order

Import objects in this sequence to ensure all references resolve correctly:

1. Cost Centres (no dependencies)

2. Locations (no dependencies; import top-level first, then children)

3. Departments (depends on Cost Centres; import top-level first)

4. Persons (depends on Departments, Locations)

5. Vendors (depends on Persons for Relationship Owner)

6. Teams (depends on Persons for Team Lead, Departments)

7. Applications (depends on Vendors, Persons, Teams)

warning

⚠️ Important: Importing objects before their dependencies exist results in empty reference fields. Follow this order, or run a second import pass to populate references after all objects are created.

---

Documentation

This guide is split into three focused sections:

People and organisation: Full attribute tables, implementation best practices, and troubleshooting for Person, Team, and Department object types.

Infrastructure and services: Full attribute tables, implementation best practices, and troubleshooting for Location, Vendor, Application, and Cost Centre object types.

Implementation and operations: Cross-object best practices, naming conventions, sandbox testing, troubleshooting guide, and frequently asked questions.

---