Agreements live on the wrong record
The template was pointed at whatever object was handy, so a contract that belongs to the Account sits on an Opportunity nobody reports from, and agreements for a custom object have no lookup to reach it at all.
Salesforce · Adobe Acrobat Sign Integration
Adobe Acrobat Sign Salesforce integration from record to signature and back
An Adobe Acrobat Sign Salesforce integration lets your teams raise agreements from the records they already work in, merge Salesforce data into the document, and write the signed values, the status and the signed PDF back to the right record. Twopir Consulting designs and configures that round trip on Adobe's managed package, for the admins, CRM owners and IT teams who have to run it. Salesforce stays the system of record for every agreement.
12+
500+
250+
40+
Trusted by 500+ organizations — Salesforce teams in legal, real estate, healthcare and software that need their agreements, data and automation to work as one system.
Integration Surface
- Salesforce Partner
- Adobe Acrobat Sign for Salesforce
- Sales Cloud
- Service Cloud
- Experience Cloud
- Salesforce CPQ
- Salesforce Flow
- Lightning Record Pages
Where the Salesforce side breaks down
Installing the package and linking the account takes hours. Most of what goes wrong afterwards is a Salesforce design problem rather than an e-signature one: the wrong master object, a mapping nobody built, a sharing model worked around instead of used. These are the six we are most often asked to fix.
The same data is typed twice
Merge mapping was never built, so reps copy names, addresses and prices from the record into the document by hand, and every copy is a chance for the signed version to disagree with Salesforce.
Signed values stop at the PDF
A PO number, a start date or a corrected address is captured on the form and never mapped back, so someone still moves the Opportunity stage and re-keys the details after signature.
Nobody trusts the status
Automatic status updates were never enabled, or quietly stopped after an upgrade, so the Agreement record shows a signature still in progress long after the customer signed, and reps go back to their inbox.
Sharing was opened to fix visibility
The package objects default to Private. When users cannot see their agreements, the quick fix is opening the org-wide default, which exposes every agreement in the org instead of following your role hierarchy.
Custom automation collides with the package
Triggers and queueable jobs chained off the package’s own updates can fail with a “Too many queueable jobs” error, and the visible symptom is a signed agreement whose record never changed.
Definition
Acrobat Sign for Salesforce, defined
An Adobe Acrobat Sign Salesforce integration is the configuration that lets Salesforce users create, send, track and file agreements from the records they already work in, and writes the results back to those records. It runs on Adobe's managed package, Adobe Acrobat Sign for Salesforce, which installs its own Agreement, Recipient, Agreement Event and Agreement Template objects into your org and connects them to your Opportunities, Accounts, Contacts, Leads, Contracts or custom objects.
Three parties are involved, and it helps to keep them apart. Adobe builds the package and licenses Acrobat Sign; according to its AppExchange listing, only senders need an account, not the people who sign. Salesforce holds the data, on any of the editions that listing names: Professional, Enterprise, Unlimited, Developer and Performance. Twopir Consulting designs and configures the integration between them: which object owns each agreement, what data moves in each direction, who can see what, and how the package stays on a supported version. Product behaviour is documented in Adobe's Acrobat Sign for Salesforce mappings and templates guide.
You will meet three names for one product. It was EchoSign, then Adobe Sign, and is now Adobe Acrobat Sign. The older names survive inside Salesforce, in the package namespace echosign_dev1 and in settings such as Adobe Sign Environment Settings, which matters when you read a field's API name or an old admin note.
Do you need a partner? A capable admin can install the package and send a first agreement in an afternoon. A partner earns its place when the decisions become structural: several master objects, signed data that has to drive automation, a Private sharing model, existing triggers on the objects the package writes to, or an upgrade backlog. This page covers the Salesforce side. For the whole engagement, from discovery to support, see our Adobe Acrobat Sign consulting and implementation services; connecting Acrobat Sign to systems other than Salesforce is covered under Adobe Acrobat Sign integration services.
The Salesforce objects behind every agreement
Every agreement sent from Salesforce becomes records in your org. Knowing which ones, and how they relate to your own objects, is what makes reporting, automation and sharing work. These are the package objects and settings we design around, with the API names your admins and developers will see.
Agreement
One record per agreement, with its status and lookups to the record it was sent from. Reporting, automation and sharing all hang off this object.
echosign_dev1__SIGN_Agreement__cRecipients
Each signer, approver or delegator, as a Contact, Lead, User, role-based group or plain email address, with its role and signing order.
echosign_dev1__SIGN_Recipients__cAgreement Events
The agreement's event history as it moves through signing. Adobe's developer guide names it as the trigger point for reacting to events.
echosign_dev1__SIGN_AgreementEvent__cAgreement Templates
Presets for one kind of agreement: name, message, language, expiry, recipients, documents and rules, plus the master object it is sent from.
echosign_dev1__Agreement_Template__cMerge Mappings
Which Salesforce fields, reached from the Agreement through parent and lookup relationships, fill which fields in the document before it is sent.
Merge Mappings tabData Mappings
What comes back: form values, constants or agreement fields written to any field on any object reachable from the Agreement.
Data Mappings tabYour Master Objects
Opportunity, Account, Contact, Lead and Contract have a Send for Signature button by default. Any other object needs a lookup field on the Agreement first.
Lookup on AgreementSigned Files
The signed PDF, audit trail and signer uploads, filed on Salesforce records. Since version 23 the package stores them as Files, with Attachments still selectable.
Files or AttachmentsMerge out, map back, status on the record
Data moves between Salesforce and the agreement at five points, and each one is configured separately. An integration that skips any of them leaves a gap someone fills by hand. When the document itself has to be generated from Salesforce data, Adobe's Document Builder extension or text tags do that part; we cover them under Adobe Acrobat Sign document automation and templates.
| Direction | What moves | Salesforce-specific consideration |
|---|---|---|
| Record → document (merge mapping) | Field values or constants merged into document fields before sending: a Lead's address and phone, or an Opportunity's product lines with quantity and price, sorted and filtered. | Traversal starts at the Agreement and climbs parent and lookup relationships only, and the related record must exist when the agreement is created. Nothing is read from a related list. |
| Record → agreement (template) | The agreement name built from record fields, recipients taken from the record, expiry calculated from a date field, and documents pulled from the record’s Files or its Opportunity quote. | A secondary object can supply data only if it has a lookup on both the master object and the Agreement object. |
| Signer → record (data mapping) | Signer-entered form values, constants or agreement fields written to Salesforce when the agreement is signed or at a stage you choose: a PO number on the Opportunity, payment details on the Account, a new Opportunity stage. | Field names come from the document, so we import them from a sample agreement signed in a sandbox rather than typing them. Mapping errors email the mapping owner; that setting is on by default and should stay on. |
| Signed files → record (file mapping) | The signed agreement, its audit trail and any supporting documents the signer uploaded, filed against every record that needs them, the Contact as well as the Opportunity for example. | Choose Files or Attachments once, and check the sharing on each record you file to, because that decides who can open the signed copy. |
| Acrobat Sign → status | The Agreement status updated as recipients act, through to a final state: Signed, Approved, Accepted, Form-Filled or Delivered when it completes; Cancelled / Declined or Expired when it does not. | Automatic status updates are switched on in step two of the package’s Setup Wizard. From version 24.14 they use a REST pull model only, and Salesforce sessions must not be locked to the IP address they started from. |
Six ways a send starts from Salesforce
The record that raises an agreement decides what can be merged into it, what can be written back, and who can see it. These are the patterns we configure most often, each with its own agreement template and master object.
Sales Contracts & Order Forms
The agreement belongs to the deal, so the deal record shows where it stands.
- Master object
- Opportunity
- Starts from
- Send for Signature, documents from the Opportunity’s Files
- Writes back
- Stage on signature, PO number, signed PDF
Quotes from Salesforce CPQ
Quote documents signed without leaving the quote process. Adobe also lists a separate Acrobat Sign for Salesforce CPQ app; which route fits depends on how quotes are produced.
- Master object
- Opportunity
- Starts from
- The Add from Opportunity Quote document source
- Writes back
- Status and signed quote on the Opportunity
Contracts, Renewals & Amendments
Agreements that outlive the deal, filed where account and legal teams look for them.
- Master object
- Contract or Account
- Starts from
- Send for Signature, expiry set from a date field
- Writes back
- Dates and status on the Contract, signed copy on the Account
Agreements Before Conversion
NDAs and applications signed while the prospect is still a Lead, and kept when it converts.
- Master object
- Lead
- Starts from
- Send for Signature on the Lead
- Writes back
- Corrected contact details; Lead Conversion Settings decide where the agreement goes
Service Cloud Cases
Authorisations and sign-offs raised from a case instead of a separate email thread.
- Master object
- Case, through a lookup on the Agreement
- Starts from
- A custom Send for Signature button tied to a case template
- Writes back
- Status and signed copy on the Case
Batch Sends From a Query
One agreement to many recipients, such as a policy update or an annual renewal.
- Master object
- The records a Salesforce query returns
- Starts from
- The Batch Agreements tab and one template
- Writes back
- An agreement per record, each with its own status
What is set in Salesforce, and what in Acrobat Sign
A working integration is configured in two places, your Salesforce org and your Acrobat Sign account, and most support tickets sit in the gap between them. We configure both sides and record which setting lives where, so your admin knows which system to open.
| Area | Set in Salesforce | Set in your Acrobat Sign account |
|---|---|---|
| Connection | The package Setup Wizard: step one links your Acrobat Sign account, step two enables automatic status updates. Re-run after upgrades that change authentication. | The Acrobat Sign account and sender licences. People who only sign need no account or licence. |
| Users and groups | The Adobe Acrobat Sign Admin and User permission sets, Group Mappings that place users in Acrobat Sign groups by Salesforce profile, and Enable Acrobat Sign Group Support to limit who can send each template. | Acrobat Sign groups, with Users in Multiple Groups enabled when one person sends for several groups. |
| Templates and documents | Agreement Templates, merge and data mappings, Send for Signature buttons, and the custom settings that shape the send page. | Library templates used as a document source, and Acrobat Sign workflows, which a Salesforce template can use only when workflows are enabled and active on the account. |
| Record pages | The AgreementPanel, AgreementPanelWide and AgreementList Lightning components on Account, Contact, Contract, Lead, Opportunity and User pages (My Domain required), or the Agreements related list. | No setting. The components read the Agreement records the status updates keep current. |
| Sharing and access | Package objects default to a Private org-wide default. Access is granted through the role hierarchy, groups, profiles and permission sets, as Adobe recommends, rather than by opening the default. | Not applicable: who can see an agreement record is a Salesforce decision. |
| Identity verification | The method per template, set separately for internal and external recipients or per recipient: email, password, phone, knowledge-based or government ID. | Phone, knowledge-based and government ID checks carry a per-transaction cost; knowledge-based checks are US only, and government ID is enabled by your Adobe success manager. |
| Environments | Environment Name set to Sandbox in Adobe Sign Environment Settings while you build, so the sandbox shows its banner and connects to Acrobat Sign’s sandbox. | Access to the Acrobat Sign sandbox environment, requested through your customer success manager. |
Six Salesforce checks before anything is built
None of these shows up in a demo. Each one has decided the shape of an integration we were asked to fix, so we check all six in the first week, before a template exists.
Edition & Org Settings
Adobe’s listing names Professional, Enterprise, Unlimited, Developer and Performance editions. Org settings matter as much as the edition.
- Session lock to the originating IP address disabled
- My Domain in place for the Lightning components
- Chatter enabled where Chatter updates are used
Automation Order & Async Jobs
The package updates records in a fixed order: attachments, recipients, the agreement, its events, then Chatter feeds. Your triggers fire inside that sequence.
- Existing triggers, flows and validation rules mapped per object
- No queueable jobs chained off package updates
- Triggers placed on the object that carries the event
Mapping Reach
Merge and data mapping follow lookups up from the Agreement, never down into related lists. The data model has to give them a path.
- A lookup on the Agreement for every object read or written
- Secondary objects linked from both master and Agreement
- Runtime values where no lookup path exists
Documents & Storage
On the Lightning send page, uploads from a computer are held to roughly 700KB by a Salesforce limit, so documents should come from Salesforce or the Acrobat Sign library.
- Files or Attachments chosen as the storage object
- Document sources set on each template
- Signed copies filed where the right people can open them
Government Cloud & Regulated Agreements
Some features behave differently by environment, so the hosting decision comes before template design.
- Chatter publisher action not available on Government Cloud
- Document Builder not supported on Government Cloud or for HIPAA agreements
- Delegator roles supported in Lightning only
Upgrade Path
Adobe supports only the latest package version and the two before it; unsupported versions are denied API access.
- Upgrades run in a sandbox first, never by uninstalling
- New picklist values added by hand where the guide says so
- Custom code retested, since package objects can change
Flow sends the agreement; the design decides when
The package gives Salesforce Flow an Apex Action that can load a template and send, remind, update, cancel or delete an agreement, so a stage change can raise the agreement without anyone pressing a button.
Routing, reminders and Flow design are covered under Adobe Acrobat Sign workflow automation.
Apex and the API, when configuration stops
For cases Flow cannot express, the package exposes a global Apex template service and batch classes, and Acrobat Sign has its own REST API. That work never modifies the managed package, so your upgrade path stays open.
It is covered under Adobe Acrobat Sign API and custom integration.
Testing the round trip before users see it
A test agreement that arrives proves the connection, not the integration. We send each agreement type from its master object in a sandbox and check every record it is supposed to change.
| Test scenario | What it has to prove |
|---|---|
| Merge on each master object | Every merged field fills from the right record, including parent and lookup values, and missing values are caught before a customer sees the document. |
| Data mapping per stage | Each mapped value lands in the right field at the right moment, and the automation it triggers runs once. |
| File mapping | The signed PDF and audit trail are filed on every record they are mapped to, as Files or Attachments as designed. |
| Every final status | Signed, declined, cancelled and expired agreements each update the record and the reports built on it. |
| Permissions by profile | Each profile and permission set sees, sends and edits exactly what the design says, with the Private default left in place. |
| Lead conversion | Agreements on a converted lead end up where the Lead Conversion Settings say they should. |
| Mapping errors | A deliberately broken mapping emails its owner, so a failure in production is reported rather than silent. |
Same architecture problem, different signing tool
Twopir Consulting has no published Adobe Acrobat Sign case study yet. The closest engagement is below, and it used Nintex and PandaDoc, not Acrobat Sign. It is here because the Salesforce side of the problem was the same: documents built from Opportunity data, signed, and the status written back to the Opportunity. Each figure is scoped to that engagement.
Contracts were assembled by copying data out of Salesforce into Word templates and sent as attachments, a process that took two to three days per deal. Documents are now generated from Salesforce Opportunity data, and signature status is written back to the Opportunity, so managers can see which deals are waiting on a signature.
What carries over to Acrobat Sign The Opportunity as master record, merged data and status written back: on Acrobat Sign those are merge mapping, data mapping and automatic status updates. Real Estate · UAE
UAE Luxury Real Estate Conglomerate
Document automation with Nintex and PandaDoc on Salesforce Opportunities.
<4 hrs Average contract turnaround, from 2–3 days
40% Faster deal closures
~10 wks Three-phase engagement, end to end
Salesforce architects, not installers
Most of the work in this integration happens in Salesforce: object relationships, automation order, sharing and release management. The signature is the last step, and it only works when the steps before it were designed.
We start from your object model
Which record owns each agreement is decided before any template is built, so reporting and sharing still work when a second team adopts it.
We read your org before we add to it
Triggers, flows, validation rules and queueable jobs on the objects the package writes to are reviewed in design, not discovered when the first signed agreement fails to update its record.
We configure both sides
Salesforce settings and Acrobat Sign account settings are set by one team and documented together, so nobody has to guess which system holds a setting.
We keep you on a supported version
Upgrades are tested in a sandbox against your templates and custom code, because Adobe supports only the latest package version and the two before it.
We hand over what we build
A documented design your admins can maintain, not a black box. When you want us to stay, ongoing Salesforce support is a standing offer.
Salesforce integration questions, answered plainly
Opportunity, Account, Contact, Lead and Contract have a Send for Signature button available by default, and the Acrobat Sign Lightning components can be placed on Account, Contact, Contract, Lead, Opportunity and User record pages. Any other standard or custom object, a Case for example, can be used once a lookup field to it is added to the Agreement object and a custom button is tied to its agreement template. The object you choose as the master object decides what can be merged into the document and written back, so we settle it before building templates.
Through data mapping. A data mapping takes a value the signer entered on the form, a constant, or a field on the agreement, and writes it to a field on any object reachable from the Agreement record, either when the agreement is signed or at a stage you choose. File mapping does the same for the signed PDF, the audit trail and any documents the signer uploaded. Data cannot be mapped to or from a related list, so the target object needs a lookup path from the Agreement.
The usual causes are configuration rather than defects. Automatic status updates are enabled in step two of the package’s Setup Wizard, and the wizard often has to be re-run after an upgrade. Since version 24.14 status updates use a REST pull model only, and Salesforce sessions locked to the IP address they started from must be disabled. Custom triggers or queueable jobs chained off the package’s updates can also fail, which Adobe’s developer guide documents as a “Too many queueable jobs” error; the fix is to make that automation synchronous or scheduled.
No. According to Adobe’s AppExchange listing, accounts and licences are required only for senders; people who only sign need neither. Senders need an Acrobat Sign licence and, in Salesforce, the Adobe Acrobat Sign User permissions, while admins also need the Adobe Acrobat Sign Admin permission set. The listing names Professional, Enterprise, Unlimited, Developer and Performance as the supported Salesforce editions.
No, and we advise against it. The package’s custom objects default to a Private org-wide default, and Adobe recommends granting access through the role hierarchy, groups, profile permissions and permission sets instead of opening the default. That keeps each agreement visible to the people who work the related record, not to the whole org.
Yes. Setting Environment Name to Sandbox in the package’s Adobe Sign Environment Settings connects a Salesforce sandbox to Acrobat Sign’s sandbox environment and shows a sandbox banner; access to that environment is requested through your Adobe customer success manager. Adobe also advises upgrading and testing in a sandbox before production, which is how we run every build and every upgrade.
Adobe supports only the latest package version and the two before it, and unsupported versions are denied API access, so upgrades cannot be put off indefinitely. Upgrade in a sandbox, never by uninstalling, which risks losing Acrobat Sign data in Salesforce. Add any picklist values the upgrade guide says must be added by hand, re-run the Setup Wizard, and retest triggers and custom code, because Adobe notes that package objects may change as the package evolves.
Next Step
Show us the record, we map the rest
A first conversation covers which records raise agreements today, what should come back into Salesforce after signature, your sharing model and your package version: enough to say what the integration involves and what it would take. No obligation to proceed.
Talk to a Salesforce architect who implements Adobe Acrobat Sign
