---
id: KB-TL-016
url: https://app.codecontract.io/help/trackline/a-file-with-many-participants
idioma: en
categoria: trackline
subcategoria: participantes
audiencia: usuario
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-TL-003, KB-TL-011]
citadoPor: [KB-TL-020]
---

# A file with many participants

_When eight companies take part in the same process and nobody knows whose turn it is._

**Responde a:** process with several suppliers at once · who must supply what in a file · file with many parties · coordinating several companies in one process

A simple file has two sides: you and someone. The troublesome ones have eight: the supplier, their subcontractor, the engineer who certifies, the client who approves, the insurer. And the jam is rarely about documents: it is about knowing whose turn it is.

## The three roles worth distinguishing

| Role | What they do | What they need to see |
| --- | --- | --- |
| The contributor | Uploads their part | Only what is asked of them |
| The reviewer or approver | Signs off | What was supplied and the criteria |
| The observer | Follows the status | Progress, not files |

> [!IMPORTANT]
> Mixing the first and third is the usual mistake: contributor access is granted to someone who only wanted to be kept informed, and documents appear uploaded by people who should not have, in the wrong place.

## How to avoid the jam

1. **Every requested item has a single owner** — If two people can supply it, neither does.
2. **Phases reflect the real order** — If the engineer cannot certify until the supplier uploads, the system should say so.
3. **Chasing goes to whoever is up** — Reminding everyone when one is missing is the fastest way to make people stop reading alerts.
4. **And it is obvious at a glance who is blocking** — It is the only question everyone asks in a file like this.

> [!WARNING]
> Beware long chains. When the person who must supply depends in turn on someone who is not in the file (the subcontractor's subcontractor), the process stalls at a point you cannot see. If that happens twice, that third party needs to become a participant.

## When someone changes midway

**En corto**

- Replace the participant, do not open another file.
- What was supplied stays: it belongs to the file, not the person.
- And the newcomer receives what is missing, not everything from scratch.

> [!NOTE]
> Each external participant enters by their link and sees only their part, with no account in your organisation. That is what makes eight parties possible without eight users to administer.

**Can they see each other?**

Only if you decide so. By default each sees their own.

**What if two supply the same document?**

Keep one and clarify who maintains it; better avoided by assigning a single owner.

**Can approval happen in parts?**

Yes, and in long files it is what stops everything waiting on the last item.

## Ejemplos

**A commissioning file involves six companies and has been stuck for three weeks.**

- Assigns a single owner to each requested document
- Orders the phases by real dependency

→ It emerges the block was a certificate depending on an uninvited third party, resolved in two days.

**Eight companies take part and nobody knows whose turn it is.**

- Assigns each document to its participant

→ Each one sees only their part.

**A participant can see another company's documents.**

- Reviews the scope of each link

→ Confidentiality does not rest on nobody looking.

**Everyone is chased when one is missing.**

- Chases only whoever has something outstanding

→ Those who complied receive no reminders.

**Two participants upload the same document.**

- Makes clear who provides what

→ Duplicated work is avoided.

**You want to know who is behind.**

- Checks progress per participant

→ The conversation happens with the right party.