The problem: signed PDFs that don't prove who signed
Your legal team keeps finding PDFs in Salesforce that say "signed" but don't show how the signer was verified, where the signature fell on a repaginated 60-page agreement, or which template version was used. Sales waits while contracts sit in someone's inbox for days. When a dispute starts, you have to stitch together emails and ask people to confirm they signed — not what you want.
What good e-signature identity and an audit trail look like
For a contract manager the essentials are simple: 1) evidence the signer is who they claim to be; 2) an unambiguous signed PDF stored on the relevant Salesforce record; 3) a readable audit trail showing timestamps and steps; and 4) signature positions that remain correct even after pagination changes.
Concrete, hypothetical scenario
Imagine a 60-page Master Services Agreement sent to a customer's Contact for signature as part of Opportunity renewal work. You do 200 renewals a month. If signature positioning breaks and PDFs aren't attached to the Opportunity or Contract record, your legal team spends hours resolving questions. If you add weak identity checks you still risk later denial. You want a short, verifiable trail and the signed file on the Opportunity or Contract immediately after signing.
How signer authentication works in Salesforce e-signature
There are several levels of signer identity you can require. Which you choose depends on risk and regulations for the contract class.
Common options you can implement from the admin side
- Signed PDF emailed to the signer and stored back to the record once complete.
- Email one-time code (OTP) required to open the signature session. That ties the session to the signer's inbox.
- Per-signer password read from a field on the signer’s Contact or User record in Salesforce. The password is supplied by the recipient before signing.
Practical setup: create fields on Contact (or a custom Signer__c object) to store signer's preferred verification method and any per-signer password. When you send from the Opportunity or Contract, the connector reads those fields and enforces the chosen checks.
Hard-coded page coordinates break the moment you insert or remove a clause. Use anchor tags in the template so signature locations move with the text. Anchor tags are simple text anchors you put in Word or PDF templates; when DocuGen generates and repaginates the final document the connector finds the anchors and places the signature there.
Example anchor text you can put in a Word template:
<>
<>
Opinion: fixed coordinates are the wrong choice for live contract templates. Use anchors so your legal team can update templates without breaking signature placement.
Where the signed document and audit data live
The signed PDF should be in the same place your lawyers look first: the Salesforce record. That means the signed PDF is filed on the Opportunity or Contract (or custom object like Contract_Request__c). Prefer Files over Notes and Attachments when the document is larger than Salesforce's 25 MB Notes limit — the connector supports files up to 40 MB.
Additionally, the signing run itself must be traceable. The sending account uses your organisation's Circularo account to perform signature collection, and the connector writes the signed PDF back to the same Salesforce record where the template was merged. Keep your template naming consistent so the legal team can match the file to the template version used.
Bundling and multi-document signature runs
If a signature package needs several documents (for example, a 60-page MSA plus a separate SOW and a Schedule), bundle them into a single signature run. That keeps all signed pages attached together and reduces the chance someone signs one but not the other. The connector supports bundling multiple templates into one run and returns a combined signed PDF to the record.
Practical checklist for legal and the admin who will set this up
- Create signer identity fields: Signer_Verification_Method__c (OTP, Password, None) and Signer_Password__c on Contact.
- Standardise anchor tag names across templates and include them in the Word files before upload.
- Store master templates in a controlled location and keep template filenames linked to version metadata in Salesforce (custom Template_Version__c field).
- Decide whether signed PDFs go to Opportunity, Contract, or both, and configure the template to file to that object.
- Use bundling when you need multiple documents signed in the same transaction.
- Test with a sandbox: send a 60-page document, include OTP and per-signer password, and confirm the signed PDF and audit info land on the record.
Triggers and automation you can rely on
Send for signature only when you want. The connector can be triggered by a button, a stage change on Opportunity, a field change (for example, Contract_Status__c), or when a new file is added to a record. That gives you the control to restrict sending to only approved deals and automates renewals when appropriate.
Closing — how Savvy DocuGen helps legal teams
Savvy DocuGen fills Word and PDF templates from Salesforce records, places signatures using anchor tags so locations survive repagination, enforces signer identity with OTP and per-signer passwords read from the signer’s Salesforce record, bundles multiple templates into one signature run, and writes the signed PDF back to the same record. Files larger than 25 MB go to Salesforce Files; everything works in sandboxes the same as production. If you need to stop chasing signers and get verifiable signed contracts filed where legal expects them, try Savvy DocuGen in a sandbox and run your own test scenario with a 60-page agreement and OTP plus a per-signer password.
Read next