Integrations
When whoever built the integration leaves
It does not break: it keeps running. The problem is that nobody knows what it does or dares switch it off.
People fear the opposite of what happens. When whoever built the connection to your system leaves, the connection does not break — it belongs to the organisation, not to that person, and it carries on working exactly the same the next day. What leaves with them is knowing what it does.
What stays, and what goes
| What | What happens to it when that person leaves |
|---|---|
| The access key | Stays active: it belongs to the organisation |
| What the integration sends and receives | Carries on unchanged, telling nobody |
| Why it was created and what breaks if switched off | Leaves with whoever built it |
| Where that key is copied | Usually the first thing lost |
Important
That last point is what really hurts: **an active key is worth the same wherever it is copied**. If it lived on the laptop of whoever left, in a script on their machine or in a note of theirs, it still opens the door from there. Removing that person's user is not enough: the user and the integration key are different things, and removing one does not touch the other.
What to do in the first few days
- 1
List the active keys and when each was last used
Last used says more than its name does.
- 2
Rotate any key for an integration that person touched
Create a new one, put it in the system, retire the old one.
- 3
Give each one a name and an owner
Which system uses it and who answers for it today, not who created it.
- 4
And retire whatever has not been used for months
It is the only thing you can switch off fearlessly, because nothing calls it.
Watch out
On switching off a key whose purpose you do not know: **disabling is not deleting**. If retiring it stops something working, you find out at once and step back by issuing another; the cost of being wrong is an afternoon, not lost data. The alternative — leaving it active just in case, forever — is the one that ends in an unanswered client questionnaire.
How not to end up here again
Worth knowing
The same applies when the one leaving is an outside provider, and all the more so: the relationship ends, the key does not, and nobody is going to remind you to withdraw it.
›Can I find out what an integration did?
The activity log shows what the key did, though not why it was created.
›What if the system using it no longer exists?
Then it is a clear candidate: retire and wait. Nothing will call it.
›Does rotating a key cut the service?
Only if you retire the old one before installing the new. Install first, retire after.
A real case
The situation
A company inherits four undocumented access keys after its developer leaves.
What you do
- Checks when each was last used, rotates the two live ones and retires the two dead ones
What you get
It ends up with two owned integrations and no doors left open from a laptop it no longer controls.
The situation
The person who built the integration leaves and nobody knows how it works.
What you do
- Documents the flow and the keys before they go
- Names a new owner on their last day
What you get
The integration keeps working and there is somebody to ask.
The situation
The integration runs on their personal account.
What you do
- Migrates to a service account before the departure
What you get
Closing their account stops breaking the flow.
The situation
The keys sit on their computer.
What you do
- Stores the keys in the secret manager
What you get
Access does not leave with the laptop.
The situation
It fails two months later and nobody knows where to look.
What you do
- Documents the log and the usual failure point
What you get
Diagnosis does not start from zero.
The situation
Nobody knows which integrations exist.
What you do
- Keeps an inventory with owners
What you get
None is orphaned.
This article answers
- the developer who built the integration left
- we do not know what this access key is for
- can I disable an old integration
- auditing access keys