A Map You Drew Once Is a Map That Is Already Wrong.

The map existed this time. Someone had done the work, perhaps after reading the earlier posts in this series. There was a register: every certificate and every credential in the production org written down, each one mapped to the integration it secured and to a named person accountable for it. The day it was finished, it was correct. You could open it, find a certificate, follow the line from the certificate to the Named Credential to the Apex class that made the callout, and from there to the person who would answer for it. It was the thing every earlier post in this series argued for, and it was real.

Then the org kept moving, the way orgs do.

The engineer who built those integrations did not leave. They stayed, as attentive and capable as the day they drew the map. The org changed around them anyway. In the first month, a managed package was installed for a new business need, and it brought its own Connected App and its own Named Credential, neither of which the engineer set up or was asked to review. In the second month, a different team repointed an integration to a new endpoint and issued a new certificate for it, and did not think to open a document they had not been told existed. In the third month, a certificate created for a proof of concept, the kind that is meant to be temporary, was quietly promoted to carry production traffic, because it was already there and it already worked. None of these was a mistake at the time. None of them crossed the desk of the person who owned the map. Each was a normal Tuesday.

The outage came in the fourth month. A certificate lapsed, an integration failed, and the engineer who built the map opened it to find the answer, because finding the answer was the whole reason the map existed. They were still there. They were good at their job. The map still failed them, because it only ever knew what they had personally written down on the day they drew it, and the org had since taken on months of changes from other hands that the map never saw. The certificate that broke was downstream of a change they were never shown. The map had been accurate. Staying in the chair did not keep it accurate, and a map that nothing keeps current is a map that lies on a delay.

This is the last post in the series, and it is the one the other five were leading to. The earlier posts taught you to draw the edges: the dependency graph, the inbound certificate, the Connected App and its tokens, and the owner mapped onto the asset. Drawing them once is an afternoon, or a week. The problem that actually takes integrations down is that the edges move and the drawing does not move with them. This post is about that gap, and about the only thing that closes it.

The org you mapped is not the org you will have.

Every shape in this series is an edge, and edges are exactly the part of an org that does not hold still.

It is tempting to read that story as a staffing problem, the kind you solve by retaining good people. It is not, and treating it as one is how the work gets deferred. Keep every admin you have, for a decade, and the map still goes stale, because the thing that moves is the org, not only the roster.

Watch the ways it moves, none of which require anyone to leave. Managed packages get installed and arrive with their own Connected Apps, Named Credentials, and remote endpoints, configured by the package and surfaced to no one in particular. Integrations get added by teams who were not in the room when the map was drawn. Integrations get repointed to new endpoints, which often means new certificates and new credentials that no one routes back into the register. Credentials get rotated on a security team's schedule, on assets a different team depends on. Integrations get retired, leaving behind credentials that still exist, still appear healthy, and now secure nothing, which is its own quiet hazard because they dilute every future review. And certificates created for a proof of concept get promoted into production by the most ordinary path there is: the thing already worked, so it stayed. People leaving is on this list too, but it is one entry, not the headline.

Read that list back and notice the common property. Not one of those changes announces itself as a change to the dependency graph, and not one of them necessarily reaches the person who owns the affected asset. Each is a routine act of building or operating the org, and each silently invalidates an edge that someone drew by hand at a single moment in time. The deeper reason a stable team does not save you is that the map never lived in the org to begin with. It lived in one person's memory and a static file. Memory is not a dependency graph: even the engineer who built every integration cannot hold hundreds of credential edges in their head, and the recall they do have is sharpest for what they touched last week and weakest for the asset that has been quietly load-bearing for three years. The map degrades not because anyone was careless, but because the org is a living system and the map is a photograph, and the gap between them widens every day whether anyone is looking or not. A register that was accurate the day you built it is wrong within a quarter, not through misjudgment, but through ordinary motion, with the whole team still in their seats.

Salesforce records the change. It does not reconcile the map.

Give the platform its due, because the gap here is precise.

When one of those changes happens, Salesforce does notice. The Setup Audit Trail logs configuration changes with the user who made them and the timestamp, and changes to certificates, Named Credentials, and Connected Apps land in it. If someone repoints an integration or rotates a credential, there is a row that records it happened.

Now read what that row is and what it is not. It is a receipt. It tells you, after the fact, that a thing was changed and by whom. It does not tell you that your dependency map is now wrong, because the platform has no idea you drew one. It does not redraw the map. It does not re-evaluate who owns the asset now that it points somewhere new. And the receipt itself is not permanent: the Setup Audit Trail retains the past one hundred and eighty days and then purges, so a change made early in a fiscal year is gone from the trail before that year closes. The audit trail is a record that something moved. It is not a system that keeps your understanding of the org current, and those are different things.

Salesforce has a dependency API. It is a snapshot, not a sentinel.

There is a sharper objection, and a knowledgeable reader will already be raising it: Salesforce does have a native way to query dependencies. It is worth taking seriously, because it is the closest the platform comes to drawing the graph for you, and it still does not solve the problem this post is about.

The object is MetadataComponentDependency, and it represents dependency relationships between metadata components in your org. You can query it through the Tooling API, and it returns directional dependencies, one row per relationship between two components. For tracing what references what inside the metadata, it is a real and useful thing.

It is also, by Salesforce's own documentation, still a beta feature, and a single Tooling API query against it returns no more than two thousand records, which a large org will exceed without trying. Set the caveats aside, though, and accept the most generous reading of it. Even then, three things remain true. It models metadata references, not the named human who is accountable for an asset, so it cannot answer the ownership question the previous post was built around. It is a query you run at a single moment, which means it tells you the org as it was the instant you asked, and nothing about how it has moved since. And running it is an act someone has to choose to perform, on a cadence someone has to remember to keep, against the same org that is changing whether or not anyone runs it.

That is the difference between a snapshot and a control. You can pull the dependency graph every quarter and you will still spend most of each quarter reading a picture of the org that is steadily diverging from the org you actually have. A picture that is correct on the day you take it and unmonitored after is not a safeguard. It is the same register from the opening of this post, generated more efficiently and decaying at exactly the same rate.

What keeps a map true is an operating model, not a document.

This is where the series has been heading, so here it is plainly. The deliverable is not a map. The deliverable is the discipline that keeps a map true while the org changes underneath it. That discipline has a few non-negotiable properties, and none of them are things the platform does for you.

The map is derived, not maintained by hand. A register that someone edits manually rots the moment attention drifts, because keeping it current competes with every other task and loses. A map that is re-derived from the live org, on a cadence and on change, cannot drift further than the interval between refreshes. The work moves from remembering to update a document to ensuring the document regenerates itself from the source of truth, which is the org, not the file.

Change is the trigger, not the calendar alone. When a certificate, a Named Credential, an External Credential, or a Connected App is created, edited, or repointed, that event is what re-evaluates the graph and the ownership attached to it. This is also where the renewal-as-approval gate from the previous post stops depending on memory. A rotation that names its blast radius and requires the dependent owners to acknowledge it is a control only if something forces the gate open every time, rather than the first time someone is in a hurry.

Ownership is reconciled against who is actually accountable now. The name on every node is checked against current reality, not against who set the asset up two years ago, and not assumed to be valid just because the same people are still employed. An owner who has left, changed teams, inherited an asset they have never looked at, or never truly owned it in the first place is a finding, surfaced before that asset causes the outage, not after.

Drift is surfaced, not discovered. The point of the whole apparatus is that the gap between the map and the org becomes a thing you are told about on an ordinary Tuesday, while there is still time to act, instead of a thing you reconstruct in a postmortem on the morning an integration is already down.

Part of this is process and part of it is tooling, and the honest division is that the platform gives you the raw material and none of the operating model. The audit trail is a receipt. The dependency query is a snapshot. Neither one watches, neither one reconciles, and neither one knows or cares whether the map you drew is still true. Closing that gap is work that has to be owned and run, the same way you would never treat backups as done because you took one once.

Where the series ends.

This series, and underneath all of it one shape. The dependency graph, the inbound certificate, the Connected App and its tokens, the owner mapped onto the asset, and now the operating model that keeps the first four true: each was a view of the same fact, which is that the risk in a Salesforce org's credential layer lives in the edges, and the native tooling shows you the nodes. A certificate is a node. The expiry date is a property of a node. Who changed it is an event on a node. What depends on it, who answers for it, and whether that is still accurate today are all edges, and edges are the thing the platform leaves you to draw and, harder, to keep drawn.

So the work was never to map the org once. Mapping it once is the easy half, and the half that feels like progress, which is exactly why so many orgs stop there with a document that is already going stale in a drawer. The work is to keep the map true while the org moves, because the org will move, and the only question is whether your understanding of it moves at the same speed or lags behind by a quarter and finds out the difference during an outage.

You have the dependency graph. The last question this series leaves you with is the only one that matters now: is anyone keeping it true.