Signers & Roles

People and permission concepts in Dropbox Sign: who signs, who receives copies, and how roles work in templates.

Signer

Brief: A person who is required to sign, initial, or fill out fields on a Signature Request.

Description: An individual designated to complete form fields (signature, initials, text, etc.) on a Signature Request. Each signer is identified by email address and name. A signer does not need to have a pre-existing paid Dropbox Sign Account — anyone with an email address can be designated as a signer. Dropbox Sign automatically creates a user account for the signer during the signing process.

An Account holder can also be a Signer on requests created by other Accounts.

Relationships:

• Belongs to a Signature Request
• Is assigned Form Fields to complete
• Maps to a Signer Role when request is created from a template
• Does not require a pre-existing paid Account — Dropbox Sign creates one automatically for signing

Important Distinctions:

• Each signer on a request must have a unique email address.
• When creating a request from a template, the role field must be specified to map the signer to the template’s pre-placed fields.
• The signer’s order (signing sequence) is different from the document’s index (document sequence).

Sender

Brief: The Account that initiates and owns a Signature Request.

Description: The Account that creates and sends a Signature Request. The sender can cancel the request, send reminders to signers, and download completed documents. The sender is not a signer by default but can be added as one.

Relationships:

• Is an Account
• Creates and owns Signature Requests
• Can send reminders to Signers
• Receives Callback Events for their requests
• Can optionally also be a Signer on the same request

CC Recipient

Brief: A person who receives a copy of the completed documents but does not sign.

Description: A CC (Carbon Copy) Recipient receives a copy of the final signed documents once the Signature Request is complete. CC Recipients do not have any fields to fill out and cannot sign.

Relationships:

• Belongs to a Signature Request
• Maps to a CC Role when using templates
• Receives completed documents (not signing notifications)

Signer Role

Brief: A named placeholder in a Template that represents a future signer to be specified at send time.

Description: A placeholder defined in a Template. Since the actual signers are unknown at template creation time, roles like “Client”, “Contractor”, “Witness” are defined instead. Form fields are assigned to these roles. When creating a Signature Request from the Template, each role is mapped to an actual person.

Example Mapping:

Template Signer Roles:
  - "Client" (order: 0)
  - "Contractor" (order: 1)
At send time:
  signers[0] = { role: "Client", email: "client@example.com", name: "Jane Doe" }
  signers[1] = { role: "Contractor", email: "contractor@example.com", name: "John Smith" }

Relationships:

• Defined in a Template
• Has Form Fields assigned to it
• Mapped to an actual Signer at request creation time

Important Distinctions:

• The role is a placeholder label; the actual signer name is provided when creating the request.
• Role matching is exact and case-sensitive — the role name in the request must match the template’s defined role name exactly.

CC Role

Brief: A named placeholder in a Template that represents a future CC recipient to be specified at send time.

Description: Similar to Signer Roles, CC Roles are placeholders in Templates for CC Recipients. They define who should receive copies but are not assigned any fields.

Signing Order

Brief: The sequential order in which signers must complete their signatures.

Description: Signing Order (also called “ordered signing”) enforces that signers must sign in a specific sequence. When enabled, only the currently active signer(s) can sign. The next signer becomes active only after the previous one completes. When signing order is disabled, all signers can sign simultaneously.

How It Works:

1. Signer with order: 0 can sign first
2. Once they complete, signer with order: 1 becomes active
3. Process continues until all signers complete
4. Signers with the same order value can sign simultaneously

Key Behaviors:

• Only the currently active signer(s) can sign at any given time
• If a signer declines, subsequent signers are never activated
• In embedded signing, a signing URL can only be generated for the currently-active signer

Important Distinctions:

• When using signing order, explicit order values must be assigned to each signer.