How to stop your CMDB becoming a write-only graveyard

The new CMDB module in FreeITSM is built around one assertion: the reason most CMDBs become write-only is that the UI surfaces records, not synthesis. You open an object and you see fields. You learn nothing in the first five seconds. So you stop opening objects.

Flip that and the data stays alive, because every visit reinforces the value of having put the data in. That's the design brief for everything below.

A CMDB stays alive when every screen tells you something useful in the first five seconds — and dies when every screen asks you to assemble knowledge yourself.

The core idea: classes, objects, and a strict little graph

FreeITSM's CMDB ships with no pre-defined classes. You define your own. Server, Database, Application, Service, Person, Team — whatever fits your estate. Each class gets its own properties (text, number, date, Yes/No, dropdown with optional per-option colours, and references to other objects).

Objects link in two distinct ways:

Properties record what the thing is. The hierarchy records what the thing belongs to. Relationships record what the thing interacts with. Each has its own table, its own UI affordance, its own semantics. The decision — "should this be a property, a parent, or a relationship?" — is the single most-asked question every CMDB user has, and the answer determines whether the data ends up legible or a hairball.

Keeping the parent rule strict (each object has exactly 0 or 1 parent, with cascade-delete on removal) is the load-bearing decision. Without it, every object can have ten reasons to exist and the diagram becomes unreadable inside twenty objects. With it, you get a navigable tree for "where does this thing live?" and a separate, explicit relationship graph for everything else.

Lead with synthesis, not fields

This is the bit that flips the write-only problem.

Open any object and the first thing you see isn't a properties form. It's a 2-3 sentence prose summary, generated on demand by Claude, that synthesises everything the system knows about the object — class, where it sits in the hierarchy, who owns it, what depends on it, and any open tickets affecting it. The boring stuff lives below.

Cached on the object's row, so reloads don't keep re-calling the AI. Click Regenerate after big changes — new relationships, new ownership — and Claude rewrites it. The prompt is locked down to factual prose only: no markdown, no bullet points, no speculation, no inventing details. If a field is missing it says so.

A real example, generated against the demo data:

That paragraph isn't stored as a string somewhere. It's generated each time, from the underlying data. Change the ownership and regenerate, and "owned by Sarah Williams" updates. Add a new database under the server and regenerate, and the descendant count updates.

The AI is the synthesis engine. The data is just data.

"If this goes down, what breaks?"

Below the summary is a structured panel that answers exactly that question, in three buckets:

Pure graph traversal. No AI required for this bit — the data structure already encodes the answer. The Impact panel just walks the relationships table and the hierarchy.

For an Active Directory object in the demo data, this panel is full: five applications use it for identity (CRM, FreeITSM, the intranet, HR, M365), three services depend on it for authentication, plus the descendants of the DC server it runs on. "What would happen if AD goes down for an hour" stops being a thought experiment and becomes a list you can read.

The live operational view

Then there's the activity layer, which is where the CMDB stops being a static inventory and starts being a live map.

Every ticket reading pane has an Affected CMDB Objects section — a pink-tinted card list where the analyst types the name of any infrastructure object the ticket touches and links it. Reciprocally, the CMDB object detail page has an Activity panel showing every ticket that references it — open and recent closed, with status pill in the lookup colour, priority, assignee, and last-updated time.

And here's the loop: the AI summary prompt now also pulls open ticket counts and the most recent five subjects. So a few weeks after you've populated the CMDB and started linking tickets, the prose synthesis at the top of any object reads less like a static facts dump and more like an operational read:

The first half of that paragraph would have been the same six months ago. The second half — the 2 open tickets, the P1 reference — is what makes opening the CMDB worth it on a normal Tuesday.

The small magic moment: the AI made a class I didn't know I needed

One detail worth calling out, because it's the kind of polish that signals the system is on your side.

When you create a fresh class — say Database — the properties manager has a ★ Suggest with AI button. Click it and Claude asks 3-5 short clarifying questions about your environment. "What kind — SQL Server, Postgres, MongoDB, Redis?". "Do you track schemas separately?". Then it suggests 6-12 properties tailored to your answers, with type, key, required flag and a one-line "why" rationale.

Some of those suggestions will be Object References — for instance, Owner → Person. If you don't have a Person class yet, the AI's hint is target_class_hint: "Person". The first version of this feature just skipped those suggestions with a "you'll need to add this manually" note. Confusing.

Now, when you click Add Selected, the system checks each Object Reference suggestion against your existing classes. If Person doesn't exist, it creates the class on the fly with the AI's suggested name, then wires the new property's foreign key to the new class — and surfaces both in the result panel:

It's a tiny detail. But it's the difference between the user feeling "the AI did its job" and "the AI hit a wall". Multiplied across every encounter with the CMDB — every class created, every object filled in, every relationship added — it adds up to a tool that feels collaborative rather than something to be wrestled.

What changes for you

The traditional CMDB pitch is "centralise your configuration data so you have a single source of truth." It's a true statement and a boring one. People know they should have a CMDB; they often have one; they don't open it.

The pitch here is different: build a CMDB that earns the next visit. Open an object and the AI has already told you what it is, what depends on it, and what tickets are touching it. The boring data is one scroll away when you actually need it. Most of the time you don't — you needed the synthesis, and you got it on the first screen.

Cross-link it with Tickets and the loop closes the other way too: when you're triaging a ticket and you link it to SQLSVR01, you're feeding the next analyst's view of that server. By the time someone else opens it next week, the AI summary will already mention the ticket. The data ages forwards, not backwards.

Combined with the rest of FreeITSM, this gives you the start of something that ServiceNow charges six figures for — an ITSM platform where the configuration map is wired into the ticketing, the tickets are wired into the changes, and every screen is doing useful synthesis on the same underlying graph. Self-hostable, free, and built so the AI features you'd expect to be premium are open by default.

A CMDB that earns the next visit. Open any object and the AI has already done the synthesis. The data ages forwards, not backwards.