Installing the Adobe Acrobat Sign package is the easy part. The work that decides whether it pays off is the design underneath: which Salesforce record starts an agreement, what data merges into the document, who signs in what order, and what comes back into the record when it is done. Twopir Consulting designs, builds and supports that layer.
Trusted by 500+ organizations — including sales, legal, real estate and professional-services teams running their agreement workflows on Salesforce with Twopir Consulting.
The Agreement Stack We Implement
Almost every organization that comes to us for Adobe Acrobat Sign help already has e-signature somewhere. The problem is not signing — it is everything around the signature. These are the six failures we see most often.
A rep exports the numbers, opens last quarter's contract, edits the client name, the term and the fee, saves a new copy, and attaches it to an email. Every step is a chance to ship the wrong figure under the right logo.
Six versions of the same MSA live in three drives and two inboxes. Legal approves one; sales uses another. Nobody can answer which clauses are actually in market, and a template change takes weeks to propagate.
The agreement is executed, the PDF sits in someone's downloads folder, and the CRM still shows the deal at "proposal sent". Renewal dates, signed values and counterparty details have to be re-keyed, or they are simply lost.
Who signs first, who counter-signs, who only needs a copy, and what happens when a signer is on leave — all of it lives in someone's head and gets enforced by follow-up emails rather than by the system.
Adobe Acrobat Sign is live, users have licences, and everyone still sends ad-hoc documents from the web app. No agreement templates, no merge mapping, no data mapping — so Salesforce gets none of the benefit it paid for.
Leadership wants to know how long documents sit unsigned, which stage they stall at, and which templates cause the most back-and-forth. Without agreement data in Salesforce, that report cannot be built at all.
Adobe Acrobat Sign is Adobe's cloud e-signature and agreement service. Its Salesforce integration is a managed AppExchange package that lets teams create, send, sign, track and file agreements without leaving Salesforce, and stores each one as an Agreement record linked to the opportunity, quote, contract, case or custom object it came from. The product was previously called Adobe Sign, and EchoSign before that; all three names refer to the same lineage.
It fits organizations whose agreements are already driven by CRM data — sales contracts and order forms, real estate transaction documents, professional-services engagement letters and statements of work, onboarding and renewal paperwork. The deciding factor is not document volume but how much of the document comes from a Salesforce record. If the answer is "most of it", the integration earns its keep. If agreements are one-off documents with no structured data behind them, a plain e-signature account will do.
Twopir Consulting is not Adobe. We implement Adobe Acrobat Sign: we design the agreement architecture, configure the package, build the automation and integrations around it, and support it afterwards. Adobe publishes the product documentation, and where a technical detail matters we link it rather than paraphrasing it — starting with the Adobe Acrobat Sign for Salesforce installation guide and the mappings and templates guide.
"Adobe Acrobat Sign consulting" covers three genuinely different engagements. Knowing which one you need is most of the scoping conversation, so here is how we separate them — and where each one ends.
You are starting from nothing, or from an e-signature process that lives entirely outside Salesforce. We stand the whole thing up — architecture first, package second.
The package is already installed and underused. We rework what is there — usually without a rebuild — so the configuration actually reflects how your teams sell, contract and renew.
Configuration has run out of road and the requirement is genuinely custom. We develop against the package's supported extension points rather than working around them.
| Requirement | Configuration handles it | Custom development needed |
|---|---|---|
| Document assembly | Agreement templates, merge mapping, and Document Builder rules for conditional sections, tables, lists and calculations. | Assembly logic that has to read data the template engine cannot reach, or compose several documents into one packet under business rules. |
| Triggering a send | A button on the record, or Salesforce Flow calling the package's Apex Action to send, remind, update, cancel or delete. | Sending from Apex — for example calling the agreement template service with runtime variables so a batch job can raise many agreements at once. |
| Recipients and routing | Recipient order, roles, authentication method and reminder cadence set on the agreement template. | Recipients resolved at runtime from hierarchy, entitlement or approval-matrix logic that has no template equivalent. |
| Writing data back | Data mapping from agreement fields, form fields and signer details into standard and custom Salesforce objects. | Post-signature processing — creating downstream records, calling an ERP or billing system, or transforming values before they land. |
| User experience | Page layouts, the standard send page, hosted signing for in-person signature, and Experience Cloud self-service signing. | A guided, multi-step send screen or an embedded journey built as custom Lightning components. |
| Large documents | Enabling the Large Documents and Push Agreements services and their dedicated callback user. | Rarely needed — but document pre-processing or external storage handoff before send usually is custom. |
The honest version: most organizations need far less custom code than they expect, and far more design than they budgeted for. We will tell you which side of this table your requirement sits on during scoping, not after the statement of work is signed.
Adobe builds these features. Our job is deciding which of them your process needs, how they should be set up, and what they should be wired to. This is the surface area of a typical engagement.
Templates carry the defaults for a type of agreement — the document, the recipient roles and order, the message, the expiry and reminder settings. We build one per real agreement type, not one per team.
Merge mapping defines what Salesforce content is pushed into the document before it is sent. Getting it right is what removes manual document preparation — and what stops the wrong figure reaching a counterparty.
Data mapping pushes document content back into Salesforce — agreement status, signer-entered form values, the signed PDF. This is the half most under-configured orgs skip, and the half that keeps CRM data honest.
A free extension package to the base app. A wizard maps Salesforce fields into a Word template and adds conditional logic for sections, tables, lists and calculations — so one template serves many deal shapes.
The package can send agreements, send reminders, update status, and cancel or delete agreements in the background. We set the triggers and the guard rails so automation never fires on a half-built record.
Acrobat Sign supports second-factor authentication for higher-value transactions, and external identity providers through its Digital Identity Gateway. Every authentication event is written to the agreement audit report.
The package ships four permission sets — user, community user, admin and integration user — and its custom objects default to Private org-wide. We map those onto your real roles instead of granting everyone admin.
A published web form can take one or more participants and multiple counter-signers, each signing in the order listed. We use them where the counterparty starts the process — applications, requests, registrations.
Because agreements are Salesforce records, they can be reported on like any other object. We build the cycle-time, stall-stage and template-performance views that make the process manageable rather than merely automated.
An agreement touches more than one system. These are the connections we build most often, with what actually moves in each direction — not a list of logos.
The core connection. Reps raise an agreement from the opportunity or quote they are already working, so the contract and the pipeline never disagree about terms, value or close date.
Out: account, contact, opportunity and quote fields merge into the document · In: status, signed PDF and signed values map back to the recordService teams need signatures too — authorizations, work acceptance, claim and warranty forms. Raising them from the case keeps the signed document attached to the interaction that required it.
Out: case, asset and entitlement data onto the form · In: completion status and captured values back onto the casePortal users can sign self-service agreements without a Salesforce licence, using the package's Simple Sign component. Useful for customer, partner and employee portals where the counterparty starts the process.
Out: portal-user context into the agreement · In: signed agreement filed against the portal user's own recordFlow is where the agreement stops being a manual step. The package exposes an Apex Action that Flow can call to send, remind, update, cancel or delete an agreement, so signature becomes one node in a larger process.
Out: Flow triggers the send and passes template variables · In: agreement status changes trigger the next FlowWhere a document is too complex for Document Builder, a dedicated generation engine assembles it and Acrobat Sign executes it. We implement both sides — see our Conga Composer implementation services and Nintex DocGen for Salesforce.
Out: generated PDF handed to the agreement · In: execution status returned to the same Salesforce recordA signed agreement is usually the trigger for something else: raise the order, start billing, file the executed copy in the document system of record. We build that handoff so nobody re-keys a contract into the finance system.
Out: signed agreement and key terms to the downstream system · In: order, invoice or archive reference back onto the Salesforce recordEvery one of these is cheap to decide at design time and expensive to reverse after go-live. They are the substance of the architecture phase.
Opportunity, quote, contract, case or a custom object — the choice decides what data is available to merge, how reporting rolls up, and who can see the agreement. To drive an agreement from a custom object you add a lookup to it on the Agreement object, then select it when building the template. Changing it later means re-mapping every template.
Teams tend to ask for one template per variation, which is how you end up with forty. Document Builder's conditional logic collapses most of those variations into a single template with rules, so the real question is which differences are business rules and which are genuinely different agreements.
Merge mapping is only as good as the record behind it. A blank billing address or a missing signatory email becomes a blank line in an executed contract. We add validation and completeness checks in front of the send action rather than trusting the person clicking it.
The package's custom objects default to Private org-wide sharing, and it ships separate permission sets for senders, community users, admins and the integration user. Deciding early who genuinely needs which one keeps commercially sensitive agreements out of general view — and avoids the usual fix of granting everyone admin.
Larger documents need the Large Documents and Push Agreements services, which require a dedicated callback user and profile plus My Domain configured for OAuth — and are not supported on Salesforce Professional Edition. This is exactly the kind of constraint that should surface in week one, not during user acceptance testing.
Upgrades are not always silent. Adobe's upgrade guide calls for testing in a sandbox from older package versions, and some releases require settings or picklist values to be added by hand that a clean install gets by default. We put a tested upgrade path and an owner in place, rather than leaving the org on whatever version it launched with.
Six phases, one continuous engagement. A focused first deployment — one agreement type with one approval path — typically runs a few weeks end to end. Breadth, not complexity, is what extends a timeline.
We walk the agreements you send today — who raises them, what data they carry, who signs, how long each step takes and where they stall. If Acrobat Sign is already installed we audit what is configured against what is used. The output is a prioritised list of agreement types, not a wish list.
We settle the six decisions in the section above and write them down: master objects, template strategy, mapping design, permission model, edition constraints and the integration boundary. This is the document the rest of the engagement is measured against, and the reason rework stays rare.
Package install or upgrade, account linking, permission sets, then the agreement templates themselves with merge and data mapping on both sides. Templates are built with legal and the people who actually send them in the room — a template signed off in isolation gets worked around within a month.
Flow and, where justified, Apex turn sending into a step in a process rather than a button someone remembers to press. Background actions, reminders and status updates are configured with guard rails. Downstream systems get their handoff. Anything genuinely custom is built here, against supported extension points.
Every template is sent end to end in a sandbox with real record shapes, including the awkward ones — missing data, a declined signature, a counterparty who never responds. Then we train by role: senders, approvers, admins. Admin training matters most, because it decides whether you need us for the next template.
A staged rollout by team or agreement type, with hypercare through the first real cycles. Afterwards we watch the data the implementation now produces — cycle time, stall stage, template performance — and tune. We also own the upgrade path, so the org does not quietly fall years behind the current package.
The pattern that makes an implementation worth doing is always the same: a repeatable document, mostly built from Salesforce data, with a signing step that has to be tracked. These are the shapes that pattern takes.
Listing agreements, reservation forms, sale and purchase agreements and disclosure packets raised from the property or deal record. Agents send from the record they are already in, and the signed set files itself back against the transaction instead of living in an agent's inbox.
The classic case, and the one with the clearest return. Pricing, term, entity and signatory all merge from the opportunity or quote, so what gets signed matches what was approved — and the signed value writes back so the forecast is not built on a number someone typed twice.
Scope, rates, named resources and duration vary per engagement but come from the same structured fields. Conditional content handles the variation in one template; the executed letter becomes the record the delivery and billing teams both work from.
High volume, low variation, high audit requirement — the easiest case to automate and the one where the audit report matters most. Authentication events are logged against the agreement, so proving who signed what and when is a report, not an archaeology project.
Several documents that must be completed together, often by more than one person on the customer side. Recipient order handles the sequencing, and data mapping writes the values the customer entered straight onto the account — no re-keying an onboarding form into the CRM.
Renewal paperwork is mostly last year's paperwork with three fields changed — which is exactly what template-driven generation is for. Because the signed agreement writes its dates back, the next renewal cycle can be triggered from the record rather than from a spreadsheet reminder.
When the counterparty starts the process — an application, a request, a registration — a published web form or an Experience Cloud signing component collects it. Web forms support multiple participants and counter-signers, so an internal approval can be built into the same flow.
Requisitions, offer letters, equipment and access forms, and internal sign-offs that currently move by email. These rarely justify a project on their own, but they are cheap to add once the agreement architecture exists — which is a good reason to design it properly the first time.
Field and support teams need a signature before work proceeds or a claim is settled. Raised from the case, signed in person through hosted signing or remotely, and mapped back so the case shows authorization status without anyone updating it manually.
These are the changes a well-implemented deployment produces. We have deliberately not attached percentages to them: the honest number is the one measured in your own org, against your own baseline, after go-live. Establishing that baseline is part of phase one.
The document is generated from the record rather than edited from last quarter's copy. The time that went into assembling it goes back to the people who were assembling it.
Terms merge out of Salesforce and signed values map back into it, so there is one version of what was agreed — not a record, a PDF and a spreadsheet that each say something slightly different.
Recipient order, reminders and status updates are enforced by configuration. Nobody has to remember who is next, and nobody finds out a week late that a signer never opened the email.
Conditional content replaces template sprawl. Legal changes a clause once and every future agreement carries it, instead of the change propagating through shared drives over the next quarter.
Agreements are Salesforce records, so how long documents sit unsigned and which stage they stall at become standard reports — and a process leaders can actually manage rather than guess at.
Once the architecture, permissions and mapping patterns exist, adding an agreement type is a configuration task rather than a project. That is the difference between an implementation and a platform.
Sales operations, contract automation and compliance on Salesforce, delivered in three phases.
The client had Salesforce, but leads were handled manually, contracts took days, compliance was a liability and commissions were run on spreadsheets. Twopir rebuilt the operation in three phases, including contracts generated automatically from Salesforce opportunities and AML compliance workflows with automated risk scoring and multi-level approval before a contract could progress. That engagement used Nintex and PandaDoc for document generation, not Adobe Acrobat Sign — we are including it because the architecture problem is identical: the agreement has to be driven by the CRM record, and the executed result has to come back to it.
Read the Full Case StudyAdobe Acrobat Sign work is rarely an e-signature problem in isolation. It is a Salesforce data, process and permissions problem with a signature at the end of it — which is the work we do every day.
Before anything is installed or reconfigured we map how agreements are raised, approved, signed and filed today. What gets built reflects that process. An implementation that starts at the package produces a faster version of a broken workflow.
As a Salesforce Partner we treat the agreement layer as part of the CRM architecture — objects, sharing, automation, reporting — rather than as a bolt-on. That is why the data mapping half of the integration actually gets built on our projects.
The boundary table earlier on this page is the conversation we have during scoping. Knowing which requirements are configuration and which are genuine development before the estimate is written is what keeps a project from doubling in the middle.
We implement Adobe Acrobat Sign, and also Conga Composer and Nintex DocGen. That means we can tell you when Acrobat Sign alone is the right answer and when it needs a generation engine in front of it — which a single-product partner cannot.
Templates change, teams reorganise, and the package gets new versions that sometimes need settings added by hand. Our Salesforce support engagements cover the agreement layer alongside the rest of the org, so there is an owner for it.
Admin training is part of the engagement, not an upsell. A team that can build its own next agreement template is a better outcome than a team that has to raise a ticket — and it is the clearest signal the architecture was designed properly.
Installing the managed package and linking the Adobe Acrobat Sign account takes hours. The implementation is everything around it: deciding which Salesforce object drives each agreement, designing the agreement templates, building merge mapping so record data flows into the document, building data mapping so signed values and status flow back, setting the permission and sharing model, and wiring the send step into Salesforce automation. Testing and user training then usually take as long as the configuration did.
A focused first deployment — one agreement type with one approval path, covering discovery, configuration, testing and launch — typically runs a few weeks end to end. What extends a timeline is breadth rather than complexity: many agreement types, many teams, several downstream integrations, or a legal review cycle on the templates. We scope the first phase deliberately narrow so something real is in production early, then add agreement types against an architecture that already exists.
They run in opposite directions. Merge mapping defines what Salesforce content is merged into a document before it is sent for signature — the client name, the pricing, the term. Data mapping defines what is pushed back into Salesforce from the completed agreement — status, signer-entered form values, the signed document itself. Most underperforming orgs have configured merge mapping and skipped data mapping, which is why their CRM still does not know what was signed.
It can, through Document Builder — a free extension package to the Adobe Acrobat Sign for Salesforce base app. A wizard maps Salesforce fields into a Word template, and conditional logic drives rules-based sections, tables, lists and calculations, so one template can serve many deal shapes. Document Builder is supported on Salesforce Lightning only, and is not supported on Government Cloud or for agreements subject to HIPAA compliance.
Where document assembly is more demanding than that — heavily formatted output, many data sources, or documents assembled into packets — a dedicated generation engine such as Conga Composer or Nintex DocGen sits in front of Acrobat Sign. We implement all three and will say plainly which combination your requirement needs.
Yes, and it is one of the most common ones. We call it configure and optimize: the package stays where it is, and we rework what sits on top of it — consolidating agreement templates, rebuilding merge and data mapping, fixing recipient routing and reminder policy, turning on background actions with proper guard rails, and adding the reporting that was never built. It is usually shorter than a fresh implementation and rarely needs a rebuild.
Yes. The managed package exposes an Apex Action that Salesforce Flow can invoke to send, remind, update, cancel or delete an agreement, and to load an agreement template — which covers most automation requirements without code. For genuinely custom cases the package also exposes a global Apex agreement template service that custom code can call with runtime variables, so an agreement can be raised from a batch job or a trigger. We prefer Flow wherever it will do the job, because a configured process is cheaper for your team to change later than an Apex class is.
Four things, in this order. How much of each document comes from a Salesforce record — if the answer is "not much", a standalone e-signature account is cheaper. Your Salesforce edition, because the Large Documents and Push Agreements services are not supported on Professional Edition. Your document sizes, since larger documents need those services and a dedicated callback user with My Domain configured. And any compliance constraint, because Document Builder is not supported on Government Cloud or for agreements subject to HIPAA compliance. We check all four in discovery rather than after the licences are bought.
What the platform does, how e-signature workflows replace paper processes, and where it fits in a client onboarding journey.
The integration itself — creating, sending, signing, tracking and filing agreements without leaving Salesforce.
For quotes, proposals, contracts, invoices and statements of work where document assembly itself is the requirement.
For organizations whose document generation is one step inside a broader automated process with approvals and workflow.
Proposal, scope and engagement-letter workflows with signed documents stored back against the CRM record.
Who owns the agreement layer after go-live — template changes, new agreement types, and package upgrades.
A first conversation is a working session, not a pitch. Bring the agreement that causes the most manual effort and we will walk through what it would take to run it through Adobe Acrobat Sign and Salesforce — including whether it is worth doing at all.
Salesforce architecture · Document automation · Agreement workflows
