Every IT team has a network diagram on a SharePoint site somewhere. It was drawn by someone who's since moved on. It still shows the old database cluster. The web server it points at was decommissioned in 2023. The IP addresses are wrong.
Nobody trusts it. Nobody updates it. Nobody can quite bring themselves to delete it either — some of it is probably still right, and the alternative is starting over from scratch.
This is what happens when the diagram and the source of truth are two different artefacts. They drift the moment anything changes, and the drift is invisible until somebody trips over it during an incident.
The Network Mapper module is built on one constraint that fixes the drift problem at the root: every node on the canvas is a binding to a real CMDB object. Not a label you typed in. Not a shape from a stencil library. A live reference to a cmdb_objects row.
If you can't draw a box without first picking which CMDB object it represents, the diagram can never drift from the data.
That one rule reshapes the whole editor. The rest of this piece is about what falls out of it — how diagram-building works when every node is bound, how related neighbours land on the canvas with one click, and how the same diagram drops straight into a board pack or a runbook without anyone redrawing it in PowerPoint.
One: the constraint
The classic flowchart workflow is "drag a shape, type a label". The Network Mapper makes you do one more thing first: bind the shape to a real object.
Drag a class tile from the palette — Server, Database, Application, whatever your CMDB defines — onto the canvas. As soon as you drop, a CMDB object picker opens, scoped to that class, with a type-ahead filter. Pick the actual object. The node is placed.
The node now carries a cmdb_object_id pointer. From that pointer, the renderer pulls the object's name, its class's icon, its planned-status flag, and its CMDB properties. Rename the object in the CMDB and the next time anyone opens the diagram, the new name is on the canvas. Flip the planned flag on and the node renders with a dashed amber border and a PLANNED pill. Decommission the asset and you can't pretend it's still there.
There's a small but real protection here too: objects already on the canvas auto-filter out of the picker. You can't place the same object twice, so the diagram and the data stay one-to-one.
And because the node is a reference rather than a copy, the diagram is cheap. The visual representation lives in three small tables — network_diagrams, network_diagram_nodes (with x, y, size, optional icon_override), network_diagram_connectors — and nothing else. Everything visible on the canvas, beyond pure layout, comes from the CMDB at render time.
Two: pull in the neighbours
A blank canvas is the worst place to start a diagram. You stare at the palette wondering which fifteen objects you really meant to include and which three you'll forget until somebody asks "where's the auth service?" in the review meeting.
The Network Mapper's answer is to start from one object and let the CMDB suggest the rest. Place a node, click it, and a detail panel slides in beside the canvas with a sticky Add related objects button at the bottom. Click that and a modal opens with everything the CMDB knows about the selected object's neighbours, split into three buckets:
This → others
Outgoing relationships. What this object depends on, hosts, connects to.
"Production DB → depends on → SAN array"
Others → this
Incoming relationships, rendered with the inverse verb so each row reads naturally from this object's point of view.
"App server → is hosted by → this"
Referenced by properties
Other objects that point at this one via an object_ref property — e.g. an owner field that names this object.
"DR plan · primary system → this"
Each row shows the related object's icon, name, class, and the verb of the relationship. Objects already on the canvas show greyed out so you can't double-place. Tick what you want, click Add N objects, and the lot drop onto the canvas at once.
The placement is intentional: new nodes lay out in a ring around the source at a radius that scales with the count so a big pull-in doesn't crowd the canvas, with the connectors drawn automatically — in the right direction for each relationship type — and the relationship's CMDB id carried on each connector for provenance. The line on the canvas traces back to a real CMDB row.
The shift this produces is the bit worth lingering on. Starting from a blank canvas and trying to recall every related object is recall-heavy and error-prone. Starting from one node and ticking which neighbours to pull in is recognition-heavy — the CMDB shows you what's there, you decide what's relevant. Diagrams get more complete with less effort, and they get more accurate because you're working from the actual graph rather than your memory of it.
Three: editor polish, document polish
The diagram exists for one of two reasons: to show someone something, or to preserve the architecture for the next person to find. The editor is built for both surfaces.
Pick a paper size from the Page dropdown — A4, A3, A2, Letter, Tabloid, in portrait or landscape — and a dashed cyan outline appears on the canvas at the actual paper dimensions. Compose your diagram inside the outline and you know what's going to print and what's going to crop. The page-size choice persists per-diagram and carries forward on save-as-new-version.
The Branding button opens a modal where you can customise the six header/footer slots that overlay the diagram — left/centre/right, top and bottom. Each slot is free text mixed with template tokens: {{logo}} renders the org-wide logo uploaded under System → Branding, plus {{title}}, {{author}}, {{version}}, {{modified}} resolve at render time. Org-wide defaults apply to every diagram by default; per-diagram overrides let you customise one diagram without affecting the rest. The strip renders only when a page outline is on, since "header" and "footer" need anchor points.
With page outline and branding set up, PNG and PDF buttons sit one click away. PNG captures at 2× the diagram's native resolution so the image stays crisp on retina screens and when projected; PDF uses the actual paper size + orientation so the file opens at the right physical dimensions for print. The same diagram drops into a board pack or a runbook without anyone redrawing it.
For live presentation, the Present button hides every bit of editor chrome — toolbar, palette, detail panel, the module nav bar at the top — and tight-fits the diagram to fill the whole screen. From there F11 takes the browser into OS fullscreen and you're presenting. Esc to come back out. Nothing to install, nothing to share-screen carefully, nothing to apologise for showing the editor toolbar.
The rest of the toolbar fills in the obvious gaps:
Each of those is small in isolation; together they make the difference between a tool you sketch in once and a tool you open every fortnight.
Why this earns the right to be the picture
The reason network diagrams die is that they're downstream of the truth. Somebody updates the asset register, somebody else logs a change ticket, an architect mentions it in standup — and the diagram, three folders deep on a SharePoint site, gets to find out about it eventually, if at all.
Making every node a binding inverts that. The diagram is no longer downstream of the truth; it's the truth in a different layout. The CMDB is the data; the Network Mapper is the picture. When the data changes, the picture changes. When the picture is uncomfortable to look at — eight objects all named "Server-01-Prod-V2-FINAL" in cramped clusters — that's not a diagram problem, it's a CMDB-naming problem the diagram has politely surfaced.
That's the move worth borrowing even if you never touch this module: figure out where the source of truth lives, then make the picture a view of it. Not a copy. Not a side-artefact. A view. Then the picture stays honest, and people start opening it again.