---
id: KB-TL-020
url: https://app.codecontract.io/help/trackline/changing-the-contact-mid-file
idioma: en
categoria: trackline
subcategoria: participantes
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-TL-010, KB-ET-018, KB-TL-016]
citadoPor: [KB-TL-003]
---

# Changing the contact mid-file

_Your contact leaves, changes role or goes off sick, and the file carries on with half of it delivered._

**Responde a:** changing a file's contact mid-way · the supplier's contact person has left · forwarding what is left to someone else · our contact person has gone

It happens in any process lasting more than a fortnight: the person supplying the documentation drops off the map. The file does not stop for that — it carries on with what they already delivered and what is still missing, which now falls to someone else.

## What stays and what changes

| Element | What happens when the person changes |
| --- | --- |
| What was already delivered | It stays, under the name of whoever delivered it |
| What is missing | Passes to the new person |
| The history of the exchange | Kept: it is what explains where you had got to |
| Links sent to the previous person | They remain live until withdrawn |

> [!IMPORTANT]
> The fourth row is overlooked and has real consequences: **sending the link to the new person does not disable the old one's**. Those are two live ways into the same file, and the departed one sits in a mailbox someone else may inherit, or that they keep if the address was personal. Changing participant is not «emailing the link to the new one»: it is granting access to one and withdrawing it from the other, two separate acts that are nearly always half done.

## The handover, in order

1. **Confirm with the company who takes over** — Do not assume it because someone answered an email.
2. **Add the new person to the file** — With their real address, not the company's generic one.
3. **Withdraw the previous person's access** — The forgotten step, and the only irreversible one if skipped.
4. **And summarise in two lines where things stand** — Delivered, missing and by when: it saves a week.

> [!WARNING]
> What delays these handovers is not the admin: **it is that the new person does not know what was asked or why**. They inherit a list of documents with no context and start asking things settled a month ago. Two summary lines when granting access are worth more than any later reminder — and if the history lives in the file rather than in the departed person's inbox, those two lines write themselves.

## When it is one of your own who changes

**En corto**

- The file passes to another team member, and that is recorded.
- What was delivered still says who requested and approved it at the time.
- And tell the third party their contact has changed: otherwise they write to whoever left.

> [!NOTE]
> If the change is because someone left the company, check scheduled sends and reminders going out in their name too: those are the ones still arriving weeks later.

**Do we have to re-request what was delivered?**

No: it stands, delivered by whoever was entitled at the time.

**What if the previous person comes back?**

Grant access again; the history has not moved.

**Can both be active at once?**

Yes, during the handover, and it helps: one is withdrawn afterwards.

## Ejemplos

**A company emails the link to a supplier's new contact and considers the handover done.**

- Adds the new one, withdraws the previous access and summarises the state in two lines

→ The file moves on without rehashing and with no live access in an unmonitored mailbox.

**The contact leaves with the file half done.**

- Changes the contact and resends what is outstanding

→ What was delivered is kept and only the gap is requested.

**The new contact does not know what was delivered.**

- Shows them the file's status

→ They catch up without phoning their predecessor.

**Reminders keep going to somebody who has left.**

- Updates the recipient in the file

→ Notices reach somebody who can act.

**A new file is opened for the new person.**

- Continues the existing one, changing the contact

→ No history is lost and nothing is requested twice.

**Nobody knows who the new contact is.**

- Asks the company's contact before chasing

→ The request reaches the right person first time.