Document Signing: Who Receives the Request Next, and Who Only Gets a Copy?

When several people must sign a document, “send for signature” is not a complete workflow specification. Decide whether everyone should receive the request immediately or whether a later signer must wait for an earlier signature. Also distinguish people who sign from people who only need the completed copy.

This guide concerns recipient routing in a software project. It does not establish whether a signature method is legally sufficient or whether a person has authority to bind an organisation. Those questions require appropriate review.

Draw the recipient sequence before designing the button

Use a fictional example: a customer signs first, a business representative signs second, and an operations contact receives notice after completion. Write down those three roles. Do not infer them from who uploaded the PDF or whose address happens to appear first in a contact record.

The Odoo 19 signature-request documentation provides a concrete sequential model. With a signing order configured, the first signer receives the request first; the next recipient receives it only once the previous recipient has signed. That is a documented product behaviour, not proof that every integration follows it.

Ask the developer to demonstrate your chosen routing. If simultaneous signing is wanted instead, make that a separate explicit requirement. Avoid adding a sequential dependency merely because a tool offers one: it can leave a request waiting on someone who is unavailable.

Show who can act now and who is still waiting

A person waiting for an earlier signer has not necessarily received anything to act on. The staff view should distinguish “not yet released”, “request sent” and “signed”, using the actual provider evidence available. These are suggested business labels, not universal provider status names.

In the fictional example, customer completion should release the representative's step, not mark the whole request complete. A delayed provider update needs an unresolved state rather than an invented signature or an instruction to start a second request.

Record the request identity, intended recipient and document version so support can explain the sequence. If an address is wrong or a signer is absent, define who may authorise a correction. Reassigning the next action must not silently claim that the previous person signed.

A copied recipient is not another signer

Odoo documents its CC field as a way to notify contacts when the document is fully signed. Keep that meaning distinct from a signing role. Adding the operations contact to CC should not be presented as collecting that person's approval.

Review the completion audience before sending. A final document may contain personal or commercially sensitive details. Decide who genuinely needs the copy and how the finished file is delivered. Do not promise that a completion notification grants portal access or withdraws previously downloaded copies.

Also specify what happens when the request expires while a later signer is waiting. Odoo documents a Valid Until date after which the document is no longer accessible through the request email link. For your implementation, agree the displayed deadline and recovery path; expiry alone does not mean that the waiting person refused.

Test the handover, not just the signature image

Use synthetic recipients and documents in an isolated test environment. Demonstrate the first request, the later recipient waiting, the release after the preceding signature and the completion notification to the copied contact. Include an expired unfinished request and a correction needing authorisation.

Inspect which messages actually exist and which document version each recipient sees. A neat signature image does not establish the routing behaviour. Put these outcomes in your acceptance criteria when planning the document workflow, with legal suitability and signer authority assigned to the appropriate reviewers.