---
id: KB-IN-018
url: https://app.codecontract.io/help/integrations/when-whoever-built-the-integration-leaves
idioma: en
categoria: integraciones
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-003, KB-IN-008]
citadoPor: [KB-IN-020]
---

# 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._

**Responde a:** 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

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.

> [!WARNING]
> 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

**En corto**

- One key per integration, never one shared across several.
- With an expiry set from the start: it forces a review and someone to claim it.
- And only the permissions needed: if it only has to read, it should not be able to write.

> [!NOTE]
> 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.

## Ejemplos

**A company inherits four undocumented access keys after its developer leaves.**

- Checks when each was last used, rotates the two live ones and retires the two dead ones

→ It ends up with two owned integrations and no doors left open from a laptop it no longer controls.

**The person who built the integration leaves and nobody knows how it works.**

- Documents the flow and the keys before they go
- Names a new owner on their last day

→ The integration keeps working and there is somebody to ask.

**The integration runs on their personal account.**

- Migrates to a service account before the departure

→ Closing their account stops breaking the flow.

**The keys sit on their computer.**

- Stores the keys in the secret manager

→ Access does not leave with the laptop.

**It fails two months later and nobody knows where to look.**

- Documents the log and the usual failure point

→ Diagnosis does not start from zero.

**Nobody knows which integrations exist.**

- Keeps an inventory with owners

→ None is orphaned.