Correspondence & Submissions

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 .eml or .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.

Evidenced Service

Evidenced service records that a document was sent, to whom, by what means and when, in a form you can rely on months later.

Where to find it

Architect Panel → Communication:

• Service Methods — the methods you serve by, and the deemed-service rule for each
• Letters — physical service through a print and post provider
• Message Log — the despatch record for electronic service

Architect Panel → Activity:

• Correspondence — the served item on the case file

Why "we wrote to you" is not enough

"We wrote to you on the 14th" is an assertion. Evidenced service is a record: the document exactly as sent, the address it went to, the method, and the timestamp. In a statutory or legal context the difference between those two decides appeals.

Keep the document as sent

This is the part most systems get wrong. If you store only a reference to a template, regenerating the letter later shows the current wording — not what the recipient received. Templates change; the served document must not.

Store the rendered document. It costs storage and settles arguments.

Service methods and deemed service

Service Methods defines how you serve and what the deemed-service rule is for each. Many statutory regimes deem service to have occurred a set period after despatch — second class post deemed served on the second working day, for instance.

Record the despatch date and let the deemed date derive from it, in working days where the rule says working days. Do not record deemed service as though it were an observed fact: it is a legal presumption, and conflating the two is exactly the kind of thing that unravels under scrutiny.

The strength of evidence differs by channel

• Letter through a print and post provider — a despatch confirmation from a third party. Strong, and independent of you.
• Email — a send record, and sometimes a delivery record. Not a read receipt, and not proof it reached a person.
• SMS — a delivery state from the carrier. Good evidence of arrival at a handset, none of who read it.
• Hand delivery — only as good as the record the person making it wrote.

Know which you have before you rely on it in correspondence, and never describe an email send record as proof of receipt.

Worked example — a licensing notice

A notice must be served on the licence holder with a right of appeal running from service. It is sent by second class post through the print provider, which returns a despatch confirmation. The service method's deemed rule adds two working days, producing the deemed service date, from which the appeal-window obligation is derived. The rendered notice, the despatch confirmation and the derived dates all sit on the case.

Worked example — a legal practice

A letter before action is served by email and by post on the same day. Both are recorded as separate service events with their own methods and deemed dates, because if the email address turns out to be wrong the postal service still stands. The rendered letter is identical in both, and stored once.

Recommendations

• Serve by two methods where the consequence is serious, and record both.
• Derive appeal and response windows from the deemed date, not from the despatch date, unless the regime says otherwise.
• Record returned mail. An address you keep serving after it bounced is one you will be asked about.
• Never regenerate a served document from a template to answer a query. Produce the stored one.

Outbound Submissions

Submissions is the outbox for the things you must send to somebody official: court filings, statutory returns, regulator portals, insurer notifications, funding claims, framework reporting.

Where to find it

Architect Panel → Integration & Connections:

• Submissions — the outbox — every submission, its state and its response
• Submission Destinations — where submissions go, and how they are transmitted

Architect Panel → Data:

• Compilations — assembled packs a submission can carry

Why an outbox rather than just sending

These sends differ from ordinary correspondence in three ways: the destination answers back, there is a deadline, and the format matters. An outbox gives you a queue you can inspect, retry and evidence — rather than a series of one-off actions somebody performed and may or may not have completed.

It also means "has the return gone in?" is a question with an answer, which is not true of a process that ends in somebody attaching a file to an email.

What a submission carries

The payload, the destination, its current state, and whatever came back. Where the destination expects a compiled pack rather than a single document, a submission can carry a compilation — the assembled set, in the required order, paginated and indexed as the recipient specifies.

Pair it with an obligation

A filing deadline that lives only in the submission is one nobody sees until it passes. Create the obligation for the deadline and link the submission to it, so the deadline escalates through the same machinery as everything else and appears in the same reports.

Failures

Watch for repeated failures against one destination. They almost always mean a format or credential problem rather than a transient one, and each retry consumes time you may not have before the deadline. Treat a second failure as a signal to look rather than to retry again.

Keep the acknowledgement

Whatever the destination returns — a receipt, a reference number, a rejection — belongs on the case. It is the evidence the obligation was discharged, and it is the first thing asked for when a regulator says nothing arrived. A submission marked "sent" with no acknowledgement stored is a submission you cannot prove.

Worked example — a court filing

A claim is filed electronically. The submission carries a compilation — the claim form, particulars and exhibits, paginated and indexed. The destination returns a case reference, which is stored on the submission and copied onto the matter. The filing deadline was an obligation, and it closes when the acknowledgement arrives rather than when somebody remembers to tick it.

Worked example — a statutory return

A quarterly return to a regulator is assembled from a saved report, submitted through the portal destination, and acknowledged with a receipt number. The obligation for next quarter is created from a schedule template the moment this one closes, so the cycle continues without anyone diarising it.

Recommendations

• Never let a submission be the only record of a deadline. Pair it with an obligation.
• Store the exact payload sent, not the query that generated it — the data will have moved on by the time anyone asks.
• Test the destination before the deadline period, not during it.
• Review the outbox as a queue, on a schedule. Anything sitting in a non-final state is work nobody is doing.