> For the complete documentation index, see [llms.txt](https://docs.allshore.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.allshore.ai/clients-and-pipeline/sending-and-countersigning.md). # Sending & countersigning ## Sending a document Send a document straight from its row. What's sent is the **file attached to it**, so a document with no file yet can't be sent, and neither can one that's already expired, terminated, or voided — only drafts and active documents go out. Recipients default to the **client's signer email** (from firmographics); you can override the recipients and add a note. The subject line and the send timestamp are set by the platform, not by the sender — what a client reads above your firm's name isn't a free-text field. Through the conversational connector (Claude, Ally), sending a document is **confirmation-gated**: the assistant must ask before anything leaves the building. Scheduled agents can't send contract documents at all — that decision stays with a person. ## Send history Every send **attempt** is recorded — not just the successful ones. Each row shows the recipients, the time the send was **requested** (not a delivery time), the outcome, and a link to the exact PDF that attempt attached. Outcomes to expect: * **queued** — requested and in progress, *or* finished without its outcome being recorded. A queued row is genuinely ambiguous: the email may already have gone out. Check with the recipient before resending, rather than assuming nothing left. * **sent** — accepted by the email provider. That's the strongest signal available here, but it is provider acceptance, not proof the client received or read it. * **failed** — the attempt did not get as far as being accepted. * **skipped** — email isn't configured on this deployment, so nothing was attempted. Read them as evidence of what the platform *did*, not of what landed in someone's inbox. The pinned PDF matters for a different reason: it's the file *that attempt* used, not the document's current file. If you regenerate a document after sending it, the history still shows exactly what was attached at the time. ## Countersigning — and the no-e-signature boundary Allshore does not do e-signature, deliberately. It generates, sends, tracks, and files — signing happens in whatever your firm and your client already use. So the loop closes like this: 1. Generate or upload the draft, and send it. 2. Signature happens outside Allshore. 3. **Upload the countersigned PDF** onto the document. 4. Set the document **active**. From that point the document counts as executed: it's cover for the platform's paperwork checks, and it becomes eligible to appear in the client's portal. Only executed paperwork ever reaches the portal — a client never sees drafts or voided documents. One current limitation worth knowing if a client says they can't find a contract: the portal's contract list reads a bounded page of the client's documents and then keeps the executed ones, so on a client with a large volume of drafts or voided rows an executed document can be missing from that list. It's still in your ledger and still downloadable by you; send it directly if a client can't see it. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.allshore.ai/clients-and-pipeline/sending-and-countersigning.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.