Approval workflow

Approval workflow — nothing goes out before the green light (1 min)Real demo — Salesforce org + Yousign sandbox · Watch on YouTube

Get a document validated before it goes out for signature — internally, on the recipient side, or both. TrueSign stacks three stages, combinable on a single request:

Stage	Who approves	When
Internal approval	1 to 3 Salesforce users	Before anything is sent — nothing reaches the provider until approved
Recipient approver	A "Needs to Approve" recipient	After sending, before signers are notified
Signers	—	Once approvals are in

Both stages work with either signature provider.

Internal approval (before sending)

In the template, designate an internal approver — plus up to two optional additional levels. At send time:

1. The request moves to PendingApproval and the first level's approver is solicited. Everything happens inside TrueSign: approval is driven by the package's own engine, not by Salesforce's native approval process — nothing to configure in Setup, and the behaviour is identical in every org.
2. Nothing is transmitted to the signature provider before approval — no API call, no email to signers.
3. Once the chain has approved, the request moves to Approved and the actual send fires automatically (Ongoing status).
4. A rejection, at any level, moves the request to Rejected with its reason.

Multi-level chain

The chain is sequential, up to 3 levels: approver 2 is only solicited after approver 1 validates, then approver 3.

• Only the current level's approver can act — the next levels see the request arrive when their turn comes.
• The interface shows the progression ("level x of y") and which levels are already validated.
• A rejection at any level stops the chain: nothing reaches the provider.
• Emergency reassignment: an administrator can reassign the current approval level to another user (absence, departure) without recreating the request — the approval-side equivalent of "Correct". The move requires admin rights and is traced in the audit log.

Reminders and escalation (SLA)

A daily job watches pending approvals:

Setting (per template)	Effect
Reminder delay	After N days without a decision, the current level's approver is chased (one reminder per period, traced in the audit log)
Escalation delay	After N days, the request escalates once to a target of your choice: the approver's manager, the next level in the chain, or a named user

The kill switch also suspends these reminders: a disabled integration sends nothing.

Conditional routing — multi-criteria rules

The approval chain can depend on the source record's data, evaluated at send time — the equivalent of DocuSign's conditional routing:

• each template carries ordered rules; the first satisfied rule wins, and provides its own chain (up to 3 levels per rule);
• if no rule matches, the template's static chain is the fallback.

Criteria

Each rule combines several criteria, each binding a field, an operator and a value:

Element	Possibilities
Field	A source-object field, or one relationship hop (Account.Industry, MyLookup__r.Field__c)
Operators	equals, not equals, greater than (strict/or equal), less than (strict/or equal), contains, is blank, is not blank
Value	Type-assisted: for a picklist or a checkbox, the valid values are offered to you

Filter logic

By default, every criterion must be true (AND). Just like Salesforce report filters, you can enter a combination formula with explicit parentheses:

(1 OR 2) AND 3

Parentheses matter: (1 OR 2) AND 3 is not 1 OR (2 AND 3). A rule with no formula simply ANDs its criteria.

Example: amount ≥ €100,000 AND discount > 10% → chain "sales manager → sales director"; otherwise → team approver alone.

Safeguards

• Fail-safe: a criterion or formula that cannot be evaluated (invalid path, incomparable value, malformed formula) counts as false — a configuration mistake never blocks a send; it simply falls through to the next rule, then to the static chain.
• Unlike DocuSign, criteria are evaluated at send time, on the Salesforce record — not mid-signature.

Recipient approver (before signers)

In the sending form or the template, give a recipient the "Needs to Approve" type — available with both providers:

• they receive the invitation before the signers and approve or reject from their email — no account to create;
• approval → their status moves to Approved, and signers are automatically notified right after;
• rejection → they enter a reason; the request moves to Rejected, with reason and author traced — signers are never solicited;
• real gate: while a decision is pending, no signer is invited;
• compatible with in-person signing and embedded mode: the signing link only becomes active after approval;
• the Correct action also works on an approver: fix their email or replace them, without recreating the request.

Tracking and traceability

• Tracking shows the request status (PendingApproval, Approved, Rejected) and each approver's individual status.
• Every approval event arrives through the webhook (approver.approved, approver.rejected): interface updated in real time, event visible in the Webhook intake card.
• Every decision — approval, rejection, reminder, escalation, reassignment — is timestamped in the audit log with its author.

The full workflow at a glance

The point to remember: while a decision is pending, nothing goes out — no provider call for internal approval, no signer invitation for the recipient approver.