These Mermaid diagrams show logical relationships and state transitions. Each
includes an enlarged SVG, an editable .mmd source and an equivalent text
explanation. The isometric walkthroughs remain on the corresponding topic pages.
System and provider boundaries
Use this view to trace durable work through Cloudflare and identify the explicit handoff to external fax, postal and email providers.
Scroll across the diagram on smaller screens, or open the full-size view.
Read the flow as text
- Clients reach Workers through the browser, native application, REST API or MCP. D1 records commitments, private R2 stores document bytes, and private services handle configured document checks.
- An outbox publisher feeds queues. A consumer claims one attempt before the provider adapter submits it.
- Telnyx fax, Pingen printing and post, and Resend email are external to Cloudflare. Verified callbacks and reconciliation return facts to the domain service; this architecture does not claim live qualification or processing residency.
Read the system architecture for component responsibilities and the distinction between implementation and live qualification.
Approval and dispatch lifecycle
Use this view to separate the immutable approval record from dispatch state, and to see where atomic acceptance ends and uncertain provider outcomes must stop.
Scroll across the diagram on smaller screens, or open the full-size view.
Read the flow as text
- A prepared dispatch identifies exact content, recipient, options and quote. A separate approval record binds that commitment and current authenticated authority.
- One D1 acceptance transaction verifies approval, reserves quota and writes the outbox before the dispatch becomes queued. A conditional claim moves an eligible attempt to submitting.
- Known provider responses can establish accepted or failed. An uncertain response or expired lease leads to submission_unknown and provider-specific reconciliation, never automatic resubmission. Later channel events describe delivery separately from acceptance.
Read the dispatch lifecycle for cancellation, delivery facts, reconciliation and financial settlement boundaries.
Data, templates and derived documents
Use this view to compare generation from mapped data and versioned templates with postal-address-page derivation from an uploaded original.
Scroll across the diagram on smaller screens, or open the full-size view.
Read the flow as text
- Parsed source data passes through an explicit mapping profile. A concrete template version and settings join those mapped inputs in a generation job, which records artifacts and provenance.
- Uploaded originals retain their identity and exact stored bytes under the applicable access and retention rules. Adding a postal address page creates a separate derived PDF; the original PDF is not an imported Studio template input.
- Derived documents still need applicable scan, validation and preview checks before later immutable approval and separate dispatch acceptance. Generation itself grants no delivery authority.
Read document workflows and Studio and data pipelines for provenance, validation and the separate authority required for dispatch.
For the persisted records behind these flows, see the separate data model and entity relationships.