Correspondence

Correspondence is the project's formal written record — the threads you'd print if the job ended up in front of an adjudicator. Delay notices, variation claims, the back-and-forth with a consultant about a detail that didn't work.

It exists because the alternative is email, and email is where a project's reasoning goes to die. A thread here has a reference number, a fixed participant list, and attachments that point at the register rather than at a copy someone downloaded in March.

Threads and reference numbers

Every thread gets a COR-### reference, numbered per project and gap-free — COR-001, COR-002, and so on. The number is assigned when the thread is created and never reused, so a reference in a letter always resolves to the same thread.

Each thread carries a type, which is a label for filtering rather than a different workflow:

→General
→RFI
→Delay
→Variation
→Claim

A thread is open or closed. Closing it records who closed it and why, as both a system post in the thread and an entry in the thread's status history. Posting to a closed thread is refused rather than silently reopening it — if the matter is live again, reopen it deliberately, and that reopening is recorded too.

The register lists date, reference, description, type, status, and participants, and filters by type, participant, and date range. Threads with something you haven't read are marked.

Who's on a thread

Participants are set per thread, not inherited from the project. There are two kinds.

Staff are people in your organisation with correspondence access. Add them from the project's members.

Externals are everyone else — a consultant, a superintendent, a subcontractor's contact. You can invite an external three ways: pick a contact from your contractor directory, pick a person who already has a login, or type an email address and a display name. All three land as the same kind of participant, so the thread doesn't care where the person came from.

Removing someone is a soft removal. They stop seeing the thread, their earlier posts stay exactly where they are, and they can be added back later.

Correspondence is staff-only inside the app

This is deliberate and worth being explicit about: trades, tenants, clients, and building managers have no correspondence access at all. The module holds commercially sensitive material — delay costs, variation positions — and none of it appears on their dashboards, in their defect lists, or in search.

An external participant reaches a thread only through the link they're sent, and sees only that one thread.

How email works here

Most systems email everyone about everything and call it collaboration. This one is deliberately narrower.

→Staff are never emailed automatically when a post lands. The thread is in the app; that's where your team reads it. The exception is being @mentioned in a post, which does email you — and if the person mentioned isn't yet a participant, whoever wrote the post is offered the chance to add them.
→External participants are emailed automatically when a post lands on a thread they're on, with a link that opens it.
→"Send as email" is the explicit action for everything else. Send a single post or the whole thread to any participants you choose, plus any additional addresses you type. It's a deliberate button press, and every send is logged with its recipients.

The net effect: nothing leaves the system by accident, and everything that leaves is on record.

Replying without an account

An external participant doesn't need a login. The link in their email opens the thread on its own page — they read the history and post a reply straight from it.

The link is scoped to that person and that thread, expires after 90 days, and only its hash is stored, never the link itself. Their reply appears in the thread attributed to them, and every other external on the thread is notified of it.

For a subcontractor's site manager who will touch your system four times in a year, this is the difference between a reply and a chased phone call.

Attaching from the registers

Attachments on a post are references, not copies. Attach an existing document, a specific drawing revision, or a photo from the project, and the post points at the register entry.

That means the thread reflects what happened to the source afterwards:

→A document that's since been withdrawn still shows on the post, marked withdrawn.
→A drawing revision that's been superseded says so, and names the revision.
→If a source is gone entirely, the chip stays with its recorded name and says it's no longer available.

The alternative — attaching a copy — quietly leaves a superseded drawing sitting in a thread looking current. This is the version that survives an argument.

Documents also work the other way: open a document and you can see the correspondence threads that reference it.

RFIs or Correspondence?

The two overlap, and the honest answer is that it depends on how formal the exchange needs to be.

Use an [RFI](/docs/rfis) for a question that needs an answer before work can proceed. RFIs have a directed inbox, a recipient, a due date, and a responded state — they're built around someone owing you a decision, and they link back to the defect or drawing pin they came from.

Use Correspondence for a matter of record rather than a question. Delay notices, variation positions, claim correspondence, anything where the point is that it was put in writing on a date and sent to named people. Threads here have references, formal participant lists, and an explicit send-and-log step.

Rule of thumb: if you're waiting on an answer, raise an RFI. If you're establishing a position, open a thread. A "Delay" or "Variation" thread type exists precisely for the exchanges that would otherwise be an RFI raised for the wrong reason.