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.