Signature providers
TrueSign can get documents signed by two engines — and the choice can be made org-wide, per template, or even per send.
| Yousign | weSign | |
|---|---|---|
| Signature level | AES and QES — advanced and qualified | SES — simple electronic signature |
| Where signing happens | At Yousign, a qualified trust service provider | Inside your own Salesforce org — no external call, no third party |
| Signer authentication | Email OTP, SMS OTP, access code, identity verification | Email OTP, access code |
| Email sending | From Yousign's infrastructure | From your Salesforce org (consumes your allowance — see below) |
| Proof | Qualified certificate, qualified timestamp | Signature certificate (identity, timestamp, IP, reading time, document fingerprint) |
| Third-party account required | Yes (Yousign account) | No |
In short: Yousign when legal value comes first (contracts, AES/QES); weSign when simplicity and autonomy come first (internal agreements, consents, low-stakes documents).
An org can run 100% weSign: the Yousign API key is then optional — no third-party account, no outbound call.
weSign produces a simple (SES) signature under eIDAS: no PKI sealing, no qualified timestamp, no identity verification. A send that requires AES or QES must go through Yousign — TrueSign explicitly refuses the send rather than silently downgrading the level. See Signature levels.
How TrueSign picks the provider
The rule is a cascade — most specific wins:
- The sender's choice in the sending screen, if they make one;
- otherwise the template's provider;
- otherwise the org default, in Settings;
- otherwise Yousign (requests predating weSign stay with Yousign).
The selected provider is stamped on the request at send time, permanently. Every later action (cancel, remind, download, refresh) routes back to that provider — changing the org default never affects requests already sent.
What weSign can do
The signing journey is hosted by your org: multiple documents, ordered or parallel signing, approvers with a real gate (no signer is invited while a decision is pending), CC recipients, in-person signing, automatic reminders, pre-expiration alerts, cancellation, correction and signer reassignment.
On signer-journey security: token-based link, email OTP (10-minute validity, 5 attempts), access code required before the PDF bytes are even served — not just in front of the sign button — and a reading gate (the document must be scrolled through), timestamped in the proof.
Three things to prepare before enabling weSign
1. Emails go out from your org — and consume its allowance. This is the difference nobody anticipates: Yousign mails from its own infrastructure, weSign mails from Salesforce. Every invitation, every one-time code, every reminder and every completion notice counts against your org's Salesforce email allowance (usually 5,000/day, but only 15/day on Developer Edition and trial orgs). TrueSign shows the allowance counter in Setup and cleanly refuses a bulk send that would not fit in what's left — rather than leaving behind envelopes nobody is ever told about.
2. Configure a verified sending address (Org-Wide Email Address) — selectable directly in Settings — with SPF/DKIM on your domain, and the org's deliverability set to "All email" (Setup → Email Deliverability). Otherwise your invitations leave from the org's default address and risk the spam folder — or don't leave at all.
3. No SMS. Your Salesforce org has no SMS gateway: SMS OTP and SMS delivery do not exist with weSign. A template requiring them must stay on Yousign.
Migrating a template to weSign
- Check that the template requires neither AES/QES nor SMS.
- Switch its provider to weSign (a blank field means it inherits the org default).
- Test a real send: signer journey, email received, proof certificate.
- Watch the email allowance counter for the first few days, especially if you do bulk sends.
Requests already in flight at Yousign are not taken over — they finish there normally.
Your brand on the weSign pages
weSign signing pages and emails are served by your org: they can therefore carry your visual identity, not a vendor's.
The application's weSign Brand tab lets you define:
| Setting | Effect |
|---|---|
| Display name | Your organization's name, as the signer sees it |
| Logo | The image shown at the top of signing pages and emails |
| Accent colour | Buttons and interactive elements |
| Ink colour | Text and headings |
| Footer text | Legal notice, contact details, or nothing |
A brand can be set as the org default, and a sending template can impose a different one — useful for a company with several trading names.
If you replace the logo, allow a few minutes before judging the result in Gmail: email clients cache images aggressively.