Capturing Correspondence
Correspondence capture attaches what arrives to the case it belongs to, so the file is complete and a colleague picking the case up can read it.
Where to find it
Architect Panel → Activity:
- Correspondence — everything captured, in and out, across all cases
Architect Panel → Integration & Connections:
- E-mail Inboxes — the monitored mailbox and what it does with what arrives
- E-mail Accounts — the credentials behind it
Architect Panel → Data:
- Documents — where the message file itself is stored
- Large Uploads — chunked upload for anything over the single-request limit
Three routes in
- A monitored mailbox — the platform polls it and applies the inbox action you configured. This is the route that scales; anything relying on staff forwarding messages will be incomplete.
- Uploaded message files — a caseworker drags in a saved
.emlor.msg. This keeps headers, recipients, timestamps and attachments intact, rather than degrading correspondence into a pasted screenshot with no provenance. - Scanned post — attached to the case, with the received date recorded separately from the scan date.
The received date is not the scan date
For anything with a statutory clock this single distinction decides whether you breached.
Post received on the 3rd and scanned on the 8th is a case that started on the 3rd. If your obligation derives from the scan date, you have quietly given away five days of a twenty-day window, and the first time anyone notices is when a response is late. Record when it arrived, and make that the date the obligation derives from.
Threading
Correspondence threads onto the record so a case shows its conversation in order, both directions. This is what makes handover work — a colleague reads the thread rather than asking what has been said, and a complainant who says "as I explained in my last email" can be checked rather than taken on trust.
Text extraction
The Document Text Extraction task indexes attachments so their contents are searchable. It ships disabled; enable it every fifteen minutes if you want to find cases by what a document says rather than only by what somebody named it. On a casework system this is usually worth it — filenames are rarely descriptive and often just "scan001.pdf".
Worked example — a council complaints inbox
A shared complaints mailbox is monitored. An inbox action creates a case from anything not matching an existing one, and threads replies onto the case they belong to by reference. Post is scanned daily and attached with the received date from the envelope. Text extraction is on, so a search for a street name finds the case whether the address was typed into a field or only appeared in a scanned letter.
Worked example — a legal matter file
Fee earners drag saved .msg files onto the matter as correspondence arrives, preserving the original headers. Because the message file is stored as a document rather than as pasted text, the file can later be produced in its original form — which matters when the authenticity of an email is the point at issue.
Recommendations
- Monitor a shared mailbox, not personal ones. Correspondence in a personal inbox is not on the file, and that person will eventually leave.
- Decide what happens to unmatched mail before you go live. Discarding it silently is the worst option — somebody wrote to you and nobody read it.
- Capture outbound too. A file showing only what arrived tells half the story.
- Keep the original file. Extracted text is for searching; the original is the evidence.