The notification arrived thirty days out, exactly as designed. A certificate in the production org was due to expire, and Salesforce sent the warning to the admins configured to receive it. They were a small group, experienced, and paying attention.
One of them opened it and looked. In Salesforce a certificate is a name and an expiry date, and little else; it does not record what relies on it. The org held dozens of certificates, the way orgs do: some self-signed, some issued for work that had long since concluded, some platform-managed and rotating on their own, most of them securing nothing still in use. From the notice alone, this one looked like the rest. The question that decides whether any expiry matters is what depends on this, and the admin who looked had no way to answer it. The certificate did not say. Nothing reachable from it in the org said either. The link between this certificate and the integration it secured was real and live in the running system, but it was recorded nowhere a person could follow from the alert. So the expiry was logged as one more routine notice, not through misjudgment but because nothing available made it anything more than that.
Thirty days passed. The integration failed on the morning the certificate lapsed, and the postmortem opened with the only question that mattered and the one nobody could answer from the org: who was answerable for this certificate, and what had it been holding up? The alert had done its job. It announced that a certificate would expire. What it could not do, and what nothing in the org could do, was connect that fact to its consequence, or to a person.
This is the fourth shape in this series. The first three traced what depends on what. This one traces who is on the hook, and it is the shape Salesforce maps least, because the platform was built to record actions, not to assign accountability.
Salesforce answers "who changed it." It does not answer "who owns it."
Give the platform credit for what it does record, because the gap is precise and overstating it helps no one.
Salesforce keeps a Setup Audit Trail that logs configuration changes with the user who made them, the timestamp, the section of Setup, and the delegate user where one was logged in as another. Certificate, Named Credential, and Connected App changes land in it. Every metadata record also carries system audit fields, a created-by and a last-modified-by, stamping who first made the asset and who last touched it. On the certificate itself, Certificate and Key Management surfaces the name, the type, the key size, and the expiration date, and the platform sends expiry notifications ahead of the lapse.
Read that list back and notice what it is. Every item is attribution of an event or a property of the asset. Who created it. Who changed it last. When it expires. Where in Setup the change happened. Not one of them is an answer to the question the postmortem asked.
The created-by field tells you who set the certificate up, which in a mature org is frequently someone who has since left. The last-modified-by tells you who touched it most recently, which is often whoever rotated an unrelated setting, not whoever is responsible for the integration it protects. The Setup Audit Trail tells you who changed it, for the past one hundred and eighty days and no further, after which the record is purged. None of these is ownership. Ownership is a forward-looking commitment, a named person who is accountable for this asset staying healthy and who must be consulted before it changes. Attribution is a backward-looking fact about who already did something. The platform is rich in the second and silent on the first.
The ownership concept exists in Salesforce. It just does not reach this layer.
The sharper architectural point is that Salesforce does have a first-class ownership model. Records carry an owner, a populated owner field that drives sharing, assignment, and accountability. An account has an owner. A case has an owner. That model is one of the platform's strengths.
It does not extend to security configuration. A certificate, a Named Credential, an External Credential, and a Connected App are not records in that sense. They are configuration metadata, governed by permissions rather than by ownership. There is no owner field to populate, no assignment to make, no sharing rule that routes accountability to a person. The ownership model that Salesforce applies so well to customer data was never wired to the credentials that customer data depends on. So the asset most likely to cause a silent outage is precisely the asset the platform gives you no native way to put a name against.
That absence is why the expiry notification in the opening story landed where it did. The alert had nowhere to go but a permission-gated list, because there was no owner to route it to. A notification that reaches everyone responsible for the org reaches no one responsible for the certificate, and a warning that everyone receives and no one owns is, operationally, a warning that did not fire.
What this shape looks like when it is drawn correctly
Owning a credential is three commitments, and none of them are native fields, so all three have to be imposed as discipline.
The first is a named accountable owner per credential and per certificate. Not the creator, not the last editor, a current person who answers for this asset. The honest place to record it today is outside the asset, because the asset has no field for it: a register, maintained deliberately, that maps each certificate and credential to the person accountable for it.
The second is the link from that asset to what it backs. The owner of a certificate is only meaningful if you also know which Named Credentials, which Connected Apps, and through them which Apex classes, Flows, and scheduled jobs fail when it lapses. That is the dependency chain the earlier posts in this series walked. Ownership without the dependency map tells you who to call; the dependency map without ownership tells you what breaks; you need both edges drawn or the notification still lands nowhere useful.
The third is renewal treated as an approval event, not a maintenance task. A certificate that backs production integrations should not be rotatable by whoever happens to hold the permission, in isolation, the way the renewal in this series' earlier posts quietly was. It should be a change that names its blast radius and requires the owners of the dependent integrations to acknowledge it before it happens. The platform will not gate this for you. The Setup Audit Trail will record that the rotation occurred, after the fact, which is the difference between a control and a receipt.
Put those three together and the failure in the opening story does not happen. The thirty-day notice reaches a named owner instead of a list. That owner can see, because the chain is drawn, exactly which integration is at stake. The renewal becomes a decision with an accountable name on it rather than a notice that goes out to a list and lands on no one.
Where this goes next
You can write an owner down once. The hard part is keeping it true.
People leave. Integrations get added, repointed, and retired. Certificates get created for a proof of concept and quietly promoted into production. A register that was accurate the day you built it is a register that is wrong within a quarter unless something keeps it current, and a renewal approval gate that depends on someone remembering to invoke it is a gate that is open the first time someone is in a hurry. Ownership maintained by hand across hundreds of assets is not a document you finish. It is an operating model you run.
That is the thread that ties this whole series together. Four shapes, the dependency graph, the inbound certificate, the Connected App and its tokens, and now the owner mapped onto the asset, are each a view of the same underlying truth: the risk lives in the edges, and the native tooling shows you the nodes. Seeing any one edge once is an afternoon's work. Keeping all four true continuously, as the org changes underneath you, is the problem worth solving, and it is the operating model the next and final post in this series takes on.