Documentation Is a Graph, Not a Pile

Most MSPs file duplicates and broken links under housekeeping. They are the things a service manager means to clean up during a slow week, right after the slow week arrives. The trouble with treating them that way is that they are the earliest visible sign that the team has stopped trusting the platform, and they keep getting worse for as long as that stays true.

Article 1 grouped hygiene and linkage as one property. They are worth separating here. Hygiene is whether the tenant is free of clutter. Linkage is whether the records are connected to one another so a technician can move between them without searching. This article covers how clutter actually accumulates, how a well-linked tenant behaves in practice, and the order of operations for cleaning one up.

How a tenant ends up with 21 copies of one document

One MSP with a mature client base went looking for its firewall staging procedure and found 21 versions of it. No two were identical, several were partially updated, and nobody could say which one a new technician should follow. Nothing unusual produced that outcome. It is the normal result of a few ordinary mechanisms running for a few years.

Duplicates get the attention because they are visible, and three other kinds of clutter usually sit alongside them. Orphan credentials are passwords tied to no device, no application, and no contact, so nobody knows what they open or whether they still work. Archived items still referenced by live documents are records someone retired properly, except that the runbooks pointing at them were never updated. And naming drift is the slow divergence of titles and labels as each technician follows their own convention, which is what makes the search failures in the first bullet so common.

The reason clutter persists is that it looks cheap to leave and expensive to fix. A team looking at thousands of records that need renaming, merging, or relinking concludes that editing every one is impossible and decides to live with the mess. Every month that decision stands, the mess gets larger.

How a linked tenant behaves from a technician's chair

Clutter is a problem of too many records. Linkage is a problem of records that exist but do not reach each other. That is what it means for documentation to be a graph: every record is a point, and every relationship is a path a technician can follow.

In a well-linked tenant, a technician who opens a device sees the credential that logs into it, the contact who owns it, the location where it sits, and the runbook that covers it. All four are clickable relationships on the same record. The credential, opened on its own, shows the device and the application it belongs to. The contact shows every asset they are responsible for. A guided procedure that spans several documents links each step to the next, so a technician never has to leave the record and search for where to go.

Two measurements describe this. Related-items density is how many connections the average record carries. Orphan rate is what fraction of records have no connections at all. A tenant with high density and a low orphan rate can be navigated. A tenant where most records stand alone can only be searched.

Linkage is also a security property, which is the part most teams underrate. A credential that is not linked to anything is a credential nobody will think to rotate when the device is replaced or the vendor contract ends, and nobody will think to revoke when the technician who created it leaves. The orphan credentials in a vault are the ones that outlive every offboarding checklist. Configurations with no linked credential are the mirror image, and they are usually the ones where the password lives in someone's head or a text file.

The random-device test

There is a quick way to tell whether a tenant is linked or merely populated. Pick a client, open the asset list, and choose a device at random. Then try to reach four things without using search: the credential that logs into it, the person responsible for it, the location it sits in, and the procedure that covers it.

If all four are one click away, the tenant is linked. If the answer is "usually," or if the technician running the test reaches for search on the second step, then what the MSP has is a well-stocked pile. Run the test on three or four clients across different onboarding eras and the pattern is usually consistent within a client and inconsistent across them.

A cleanup sequence that holds

Cleaning up a tenant is a solvable problem when it is done in the right order. Done in the wrong order, it creates a second round of the same mess.

Done by hand, this is the project every service manager postpones, because it is a lot of evenings of copy and paste. That is the reason it rarely happens, and the reason the approach below matters.

How Lexful gets you there

The cleanup sequence above is exactly the kind of work Lex is built to do at tenant scale, with a technician reviewing and approving each change.

• Duplicate detection across every record: Ask Lex to find duplicate and overlapping documents, credentials, and assets across all clients and it returns the clusters with the differences between copies called out, so the consolidation decision becomes a quick review.
• Merge and archive with approval: Lex drafts the consolidated version, the team approves it, and Lex then produces the list of what should be archived, which happens as a single filtered action.
• Mislink cleanup: Ask Lex to find every document that references an archived or inactive asset, and it flags each reference and proposes the replacement, which clears the archived-but-referenced clutter in one pass.
• Related items and inline links as first-class fields: Every relationship is a clickable field Lex can read and write, so relinking a client's devices to their credentials, owners, and locations starts with a single prompt.
• Tags that carry structure and permissions: A shallow set of tags organizes records that once sat four or five folders deep, and a tag can carry a security group with it.
• Search that reads every field: Because Lex indexes titles plus the contents of every field, attachment, and relationship, the technician who cannot remember what a document was called still finds it, which removes the mechanism that created most of the duplicates.

Where this series goes next

Complete, fresh, and clean records for one client are a real accomplishment. The last three properties in the series ask whether the same is true for every client at once, and whether the documentation can prove it to someone outside the MSP. The final article covers standardization, accuracy, and compliance, which together decide whether a tenant that passes for one client passes for all of them, and whether it holds up when an outside party starts asking for evidence.