Signer vs recipient in an e-signature request

Why tools invented extra roles

Large organisations wanted the software to mirror their approval chains, so vendors added roles that do not sign: an approver who blesses a document before it goes out, a copy recipient who gets a file for their records, an agent who fills fields on somebody's behalf. Each addition made the routing model more expressive and the interface more confusing. Smaller teams rarely need any of them, because an approval that leaves no mark on the document is usually an internal step that belongs before sending rather than inside the signing flow.

What the distinction changes in practice

Three things. Whether the person has fields, which decides if the document waits for them. Whether they count for completion, since an envelope finishes only when every signer has signed. And what appears about them in the finished record, because a signer's verification method, signing time and address are printed on the certificate of completion while an observer's are not. Getting the role wrong is the usual cause of an envelope that sits at partially signed forever, waiting for somebody who never had anything to do. The distinction also shapes chasing. A document stuck at partially signed has a specific person to contact, and the status page names them, which turns a vague follow up into a message to one address. Where a list mixes people who must act with people who were added for visibility, that clarity disappears and the sender ends up chasing everybody, which is both slower and mildly insulting to the people who already signed. Naming one person for each action, and keeping observers off the list entirely, keeps the chase list short and accurate.

The roles that exist here

Two, and only one of them is created by adding a person. Every recipient added to an envelope is a signer, and the interface offers no role picker. The other is in person signing, which is not a separate person but a way for an existing recipient to sign on the sender's device during a hosted session. The underlying interface accepts approver and copy recipient values, but nothing in the product ever sets them, and the two document handovers from forms and documents both create signers. Treat approver and copy recipient as absent rather than hidden.

Arranging a document when the role is missing

A witness becomes a signer placed after the person they witness, with their own signature, printed name and date fields in the attestation block. An approver becomes either an internal step before sending or a signer with an initials field, depending on whether their agreement needs to appear on the document. Somebody who only needs a copy is simply left off, since everyone who was on the envelope receives the completed file by email at the end. Each of these is a modelling decision made once per document type, then reused.

Order, and who waits for whom

With sequential routing switched on, only the lowest outstanding position is invited and the server refuses any attempt to sign out of turn, so roles and order interact: a witness placed before the signer would be invited first and have nothing to attest. With it off, everyone is invited at once. The order is set by list position when the envelope is prepared, and it cannot be rearranged after sending, which is another reason to decide roles deliberately rather than adding people as they come to mind.

What each recipient sees before authenticating

Before any identity check is passed, the invitation and the pre authentication screen carry only the envelope title, the sender's message, the recipient's own name, email and role, which verification method applies, and the consent version. Nothing about the document contents is exposed. That matters when the recipient list includes people at different organisations, because it means a mistyped address leaks a title rather than an agreement. The document itself appears only after the check succeeds and a signing session exists.

Questions people ask