Object schemas, attributes, and references explained, plus the design decisions that determine whether your CMDB stays accurate or quietly rots within a year.
Most configuration management databases fail the same way. They are built accurately, celebrated briefly, and then rot, because nothing in the organization depends on them being current. Atlassian Assets is a good tool. Whether your CMDB survives depends almost entirely on design decisions made in the first month.
Assets, formerly Insight, ships with Jira Service Management Premium and Enterprise. It is a flexible object database that lives alongside Jira and can be referenced directly from issues. You define object schemas, each containing object types with attributes, and objects can reference other objects to form a graph.
The flexibility is the point and also the trap. Assets will happily let you model anything, including things you have no way to keep current.
The most common design mistake is modelling everything you own. Start instead with the questions you need answered, then model only what is required to answer them.
Useful questions look like: which laptops are assigned to people who left, which applications would be affected if this server goes down, which vendor contracts renew in the next 90 days, and who approves changes to this system. Each of those implies a small, specific set of object types and references. Together they define a schema that earns its maintenance.
Keep object types shallow. Deep inheritance hierarchies feel elegant during design and become unmaintainable in practice. Prefer a flatter structure with clear attributes.
Use references rather than duplicated text. If a laptop has an owner, reference the person object rather than storing a name string. References are what make Assets more useful than a spreadsheet, and text fields are how a CMDB quietly becomes a spreadsheet.
Name attributes for humans. Agents will read these in the middle of an incident. Clarity beats brevity.
Decide the source of truth per object type, before you build it. Every object type should have one system that owns its data and one mechanism that keeps it current. If you cannot name that system, do not model the object type yet.
Manual maintenance fails. It always fails, and it fails quietly, which is worse. Design for automated inflow from the start.
Assets supports scheduled imports from common sources: directory services for people, endpoint management tools for hardware, cloud provider inventories for infrastructure, and CSV or database imports for everything else. Configure these before the CMDB goes live, not after it has already drifted.
Where automation is genuinely impossible, build the update into an existing workflow rather than asking someone to remember. Hardware assignment should update when the fulfilment request closes, not when someone finds time.
Assets pays off when objects are referenced from issues. Attach the affected service to an incident and you can see its dependencies immediately. Attach hardware to a request and approvals can route on cost centre. Attach applications to change requests and you can answer what else this touches without a meeting.
Beyond IT, we have seen useful schemas for HR equipment lifecycles, procurement vendor catalogues with renewal dates, and security application inventories with risk ratings. The pattern is the same: things worth tracking, relationships worth traversing, and an automated source keeping it honest.
Guides only take you so far. Bring the messy specifics and we will tell you what we would actually do.
.webp)