Nobody owns the master copy
The approved wording lives in someone's downloads folder, in last quarter's agreement and in three slightly different templates. Senders pick whichever they find first, and legal finds out at renewal.
Adobe Acrobat Sign · Document Automation & Templates
Adobe Acrobat Sign document automation that builds the agreement for you
Adobe Acrobat Sign document automation means every agreement is assembled from your data and an approved template, with its fields, rules and signature blocks already in place, instead of being edited, retyped and marked up by hand before each send. Twopir Consulting designs and builds those templates: Document Builder and agreement templates in Salesforce, and library templates, text tags, smart fields and web forms in Acrobat Sign. Fewer hand-built documents, and a template library your admins can still manage.
12+
500+
250+
40+
Trusted by 500+ organizations — including healthcare, legal and professional-services teams that produce their agreements, forms and onboarding documents from Salesforce with Twopir Consulting.
What We Build With
- Salesforce Partner
- Adobe Acrobat Sign for Salesforce
- Acrobat Sign Document Builder
- Agreement Templates
- Library Templates
- Text Tags
- Web Forms
- Merge Mappings
The signature is digital, the document is still manual
Most teams moved signing online years ago. The document in front of the signer is often still put together by hand: copied from an old version, filled from the record by eye, and marked up with fields on every send. These are the six document problems we are asked to fix most often.
Fields are placed by hand on every send
Signature, date and initial fields are dragged onto the document each time. One missed initial or a field assigned to the wrong signer sends the agreement back for a second round.
Line items are retyped from the record
Products, quantities, prices and addresses already sit in Salesforce, yet someone copies them into a Word table before sending. Every copy is a chance for the document and the record to disagree.
One form tries to fit every case
A single long form carries the sections for every product, region and customer type, so signers wade through fields that do not apply to them and write "N/A" in the rest.
Signers can type anything
Dates arrive in three formats, totals are added up by hand, and a phone number field accepts a sentence. The agreement is signed, and the data inside it still has to be cleaned before anyone can use it.
Forms still travel as email attachments
Applications and requests go out as PDFs, come back printed, scanned or half-filled, and are typed into the system by whoever opens the inbox. The process starts with a download instead of a link.
Definition
Document automation, defined
Adobe Acrobat Sign document automation is the practice of producing agreements from approved templates and live data, with signature and form fields, rules and checks defined once in the template rather than added by hand on every send. In a Salesforce org that means agreement templates, merge mappings and Document Builder, which generates a document from Salesforce data in a tagged Word template. In Acrobat Sign itself it means library templates, text tags, conditional and calculated fields, and web forms.
Three parties are involved, and it helps to keep them apart. Adobe builds Acrobat Sign, the Salesforce package and its Document Builder extension, and decides what each one can do; its Document Builder guide and its text tag guide are the reference. Salesforce holds the records the documents are built from. Twopir Consulting designs the template model and builds it: which documents become templates, where each value comes from, how fields behave, who owns each template, and how it is tested.
This page is about the document, not the plumbing or the process around it. Package setup and the mechanics of mapping data back into Salesforce are covered under Adobe Acrobat Sign Salesforce integration; routing, approvals and reminders under Acrobat Sign workflow automation; code against the REST API under Acrobat Sign API integration; and Microsoft, HR and ERP connectors under Acrobat Sign integration services. If your documents are already generated in another tool, our Conga document generation and Nintex DocGen pages cover that side. The whole engagement model is on our Adobe Acrobat Sign consulting and implementation page.
Choosing how each document gets built
Acrobat Sign offers several ways to turn data into a ready-to-sign document, and they are not interchangeable. The first design decision is which method each document uses. The rule we start from: if the wording is fixed and only the values change, merge into a fixed document; if the content itself changes with the record, generate it.
| Method | What it produces | Best for | What to know before building |
|---|---|---|---|
| Document Builder | A document generated from the master record and its related records, using a Word template tagged with Adobe's free Document Generation Tagger add-in, previewed against a sample record before saving. | Documents whose content changes per record: quotes, order forms and proposals with line-item tables. | Salesforce Lightning only; not supported on Government Cloud or for agreements subject to HIPAA compliance. Needs package version 24.0 or later, and one Document Builder template per agreement template. |
| Merge mapping into a fixed document | Salesforce field values, or constants, written into the fields of an existing document before it is sent, including Opportunity product lists. | Agreements with approved, fixed wording where only names, amounts and dates change. | Values are reached from the agreement through parent and lookup objects, and the association must exist at runtime. |
| Text tags | Fields written as tagged text inside a Word, PDF or other document and converted into real fields on upload, with role, required, read-only, validation and show-if rules. | Documents created outside Acrobat Sign that must arrive with every field already placed and assigned. | Some field types depend on the service level: participant stamps and transaction IDs need business or enterprise, digital signature fields need enterprise. |
| Library template | A reusable document stored in Acrobat Sign with its fields authored once, shared with a group or the whole organization. | Standard documents sent from both Acrobat Sign and Salesforce, and any document a workflow template uses. | The Acrobat Sign Library is a document source inside Salesforce agreement templates, so one library template can serve both. |
| Web form | A published form, shared as a link or embedded in a site, that the signer fills and signs on any device; submissions export as CSV. | Documents the other party starts: applications, requests and registrations. | Each submission creates its own agreement, so naming and reporting are designed around many agreements from one form. |
| Conga Composer or Nintex DocGen, then Acrobat Sign | The document is generated by the existing tool and sent through Acrobat Sign, which Adobe lists among the document apps its Salesforce package works with. | Orgs that already run their document generation in one of those tools. | The template lives in the generation tool. Signature fields can travel in the generated document as text tags. |
Six parts of a document that builds itself
A template is only as good as the record data behind it and the rules inside it. We design each of these against your real records, build them in a sandbox, and test them on the awkward cases before anyone sends.
Document Builder Templates
Word templates generated from Salesforce data, for documents whose content changes with the record, built and previewed against sample records before they go live.
- Fields from the master object and up to five levels of lookups
- Related-record tables, sorted and filtered by query
- Tags placed with Adobe's Document Generation Tagger
- Admin, User and Community User permission sets
Agreement Template Design
Salesforce agreement templates that preset everything about the document, so a sender starts from the right one instead of a blank agreement.
- Agreement names built from record variables
- Document sources: Files, the Acrobat Sign Library, quotes
- Merge mappings for fixed-wording documents
- E-signature or written signature per template
- Password protection on the signed PDF
Text Tags & Field Authoring
Fields defined in the document itself, so they arrive in the right place, for the right signer, on every send without anyone dragging them on.
- Signature, initial and data fields assigned by role
- Checkboxes, radio buttons, drop-downs and attachments
- Required and read-only markers
- Shortened tags for field names used again and again
Conditional, Calculated & Validated Fields
Fields that respond to what the signer enters, so the form stays short, the totals are right and the data comes back usable.
- Show, hide, enable or disable on any or all conditions
- Calculated totals and dates with number, currency or date formats
- Validation for text, numbers, currency, percentages and dates
- Sender prefill for values only your team should set
Web Forms
Forms the other party opens from a link or your website and completes on any device, replacing the PDF that was downloaded, printed and scanned back.
- Counter-signers and copy recipients set on the form
- Fields authored once, edited later without a new form
- Submission data exported as CSV
- Naming that keeps one agreement per submission findable
Template Governance
The rules that keep a template library usable after the tenth template and the third admin: who owns what, where the master lives, and how changes are tested.
- One master per document, with a named owner
- Sharing set by user, group or organization
- Naming and retirement rules for old versions
- A regression set re-run after package upgrades
Six documents, built from the data
Every template answers the same three questions: where its data comes from, what builds it, and how its fields behave. Three of these follow examples Adobe gives in its own documentation; the other three are the Salesforce patterns we design most often.
Proposal with Line Items
The proposal is generated from the opportunity, with its products listed in a table instead of pasted in by the rep.
- Data
- Opportunity, account and the related product records
- Built with
- Document Builder, with the table sorted and filtered
- Fields
- Signature blocks placed in the Word template
Order Form That Totals Itself
One of Adobe's calculated-field examples: the signer picks items and quantities, and the form works out the price.
- Data
- Items and quantities chosen by the signer
- Built with
- A library template with calculated fields
- Fields
- Currency-formatted totals, validated quantities
Contract with a Chosen Term
Another of Adobe's examples: the customer chooses the contract length at signing, and the end date fills in from that choice.
- Data
- Start date and the term selected by the signer
- Built with
- A calculated field with a date format
- Fields
- End date calculated and formatted as a date
Public Application Form
Adobe's government grants recipe: a relief application published as a web form, completed and signed online instead of on paper.
- Data
- Entered by the applicant on any device
- Built with
- A web form with a counter-signer and copy recipient
- Fields
- Submissions exported as CSV for review
Onboarding Packet with Optional Sections
One packet for every customer type, where the fields that do not apply never appear to the signer.
- Data
- Account details merged from the record
- Built with
- An agreement template and a text-tagged document
- Fields
- Extra fields shown only when an answer calls for them
Fixed-Wording Agreement
A standard NDA or service agreement where legal controls the wording and Salesforce supplies the names, dates and amounts.
- Data
- Contact, account and contract fields
- Built with
- Merge mapping into a library document
- Fields
- Merged values read-only, so signers cannot change them
Where Document Builder stops and what we use instead
Document Builder and Acrobat Sign's smart fields cover most agreement documents, but Adobe documents clear limits on both. We check them against your org and your licence in design, so nobody discovers them after the template is built.
| Situation | What Adobe documents | How we handle it |
|---|---|---|
| Your org runs on Salesforce Government Cloud | Document Builder is not supported on Government Cloud, and the option is disabled there. | Merge mapping into a fixed or text-tagged document, with any variable sections handled by conditional fields. |
| The agreement is subject to HIPAA compliance | Document Builder is not supported for agreements subject to HIPAA compliance. | Those agreement types are kept on merge-mapped templates; other document types can still use Document Builder. |
| Some users still work in Salesforce Classic | Document Builder is supported only on Salesforce Lightning. | Senders of generated documents move to Lightning first, or keep a merge-mapped template until they do. |
| The data sits deep in related records | Up to five levels of child-to-parent lookups, and Salesforce allows no more than 20 parent-child relationships in one query. | Bring distant values onto the master record with a formula or lookup, and keep the template's data model shallow. |
| You want calculated fields on your plan | Calculated fields are part of Advanced forms, included only with multi-license service levels. | Calculate in Salesforce before sending and merge the result into a read-only field. |
| Documents need assembly logic beyond one template | One Document Builder template per agreement template. | Separate agreement templates by document type, or a dedicated generation tool such as Conga Composer or Nintex DocGen with Acrobat Sign for signing. |
Templates, tags and field rules
Document Builder and agreement templates, merge mappings, library templates, text tags, conditional, calculated and validated fields, and web forms.
Built so a Salesforce admin can read it, change it and test it.
When the document outgrows the template
Complex multi-document assembly belongs in a generation tool, and documents created from another system belong in code against the REST API, covered under Acrobat Sign API integration.
We recommend a second tool only when the first one has run out.
Keeping the template library clean at scale
Template sprawl is rarely a tooling problem. It happens when nobody decided who owns a template, where the master lives or how a change is tested. These are the defaults we set in every engagement, and change only when your process needs something different.
| Decision | Our default | Why it matters |
|---|---|---|
| One template or many | One template per document structure; variations handled by conditional fields, filtered tables and runtime variables. | Every extra copy is another place where the approved wording can drift. |
| Where the master lives | Fixed documents as Acrobat Sign library templates, shared to the group that uses them; generated documents in Document Builder. | Salesforce agreement templates can use library documents, so one master can serve both places. |
| Who may change a template | A named owner per template, and Document Builder Admin access limited to the admins who maintain it. | Senders get the User permission set and send; they do not edit the template. |
| How templates are named | Document type, audience or region, and version in the name; replaced versions retired, not left in the list. | Senders pick from a list. A clear name is the cheapest control there is. |
| How a change is tested | In a sandbox, previewed against a fixed set of sample records that includes the awkward ones: no line items, long names, missing values. | Document Builder previews against a sample record, and the edge cases are where documents break. |
| What happens at upgrade time | The same sample set re-run after each managed-package upgrade. | Adobe notes its package objects may change as it evolves, and supports only the latest three versions. |
From a folder of documents to a governed library
A focused first deployment, one agreement type with one approval path, typically runs a few weeks end to end. What extends a timeline is breadth: more document types, more variants of each, and more records that the data has to be pulled from.
Inventory the Documents
We collect every version of every agreement and form in use, find the duplicates, and agree which wording is the approved one.
DeliverableDocument inventory and the master list
Design the Template Model
For each document: the build method, where every value comes from, which fields are conditional, calculated or read-only, and who owns it.
DeliverableTemplate design, signed off by the document owner
Build in Sandbox
Templates, tags, mappings and forms built against an Acrobat Sign sandbox environment where your account has one, which Document Builder supports.
DeliverableWorking templates, demoed on your records
Test on Real Records
Every template previewed and sent against the sample set: empty tables, long values, missing lookups, each conditional path and every signer role.
DeliverablePassed test matrix and owner sign-off
Release & Retire
New templates released with the old copies removed on the same day, and short training for senders and the admins who will own the library.
DeliverableLive library and admin runbook
Govern & Extend
We add the next document types to the same model, review requests for new templates against it, and re-run the sample set after each upgrade.
DeliverableTemplate register and an upgrade checklist
Documents built from the record, not the clipboard
We do not have a published Adobe Acrobat Sign case study, and we will not present another tool's results as one. This engagement generated its documents with Nintex and sent them for signature with PandaDoc. It is here because the document design is the same: data comes from the Salesforce record, never from someone retyping it. Each figure is scoped to that engagement.
Same Document Design
Agents used to copy data out of Salesforce, paste it into Word templates and check it by eye before sending. Property contracts, offer letters and KYC onboarding forms are now generated from Salesforce opportunity data the moment a deal reaches the document stage, and the error rate on documents went to near-zero because the data comes straight from the CRM.
What carries over to Adobe Acrobat Sign The template model and the data source. The generation and signing tools were different.
UAE Luxury Real Estate Conglomerate
250+ agents on one Salesforce platform, delivered in three phases.
<4 hrs Average contract turnaround, from 2–3 days
80% Less manual data entry, across the engagement
250+ Agents and brokers on the platform
Template design from CRM data architects
A generated document is only as accurate as the record behind it. Most template problems turn out to be data problems, which is why we start with the data model and finish with the Word file.
We fix the data before the template
If a value is missing, stale or three lookups away, the document will show it. We bring the fields a template needs onto the record it is built from, before anyone designs a layout.
We build fewer templates, not more
Conditional fields, filtered tables and runtime variables let one template cover the variants that used to need five. The library gets smaller as it covers more.
We check the limits against your org
Lightning, Government Cloud, HIPAA-subject agreements and service level all decide what is available. We confirm them in design, so the method chosen is one you can actually use.
We are not tied to one generation tool
We also implement Conga Composer and Nintex DocGen, so the recommendation follows the document, not the tool we know best.
We hand over a library, not a pile of files
A template register, owners, naming rules and a test set your admins can run. When you want us to stay, Salesforce support and managed services keep the library current.
Acrobat Sign template questions, answered plainly
No. Adobe documents that Document Builder is supported only on Salesforce Lightning, is not supported on Government Cloud, and is not supported for agreements subject to HIPAA compliance. It also needs Adobe Acrobat Sign for Salesforce version 24.0 or later, and it installs as an extension package that Adobe says requires no additional purchase. Where it is not available, we build the same document as a merge-mapped or text-tagged template instead.
Usually, yes. Conditional fields show, hide, enable or disable fields based on what the signer enters; Document Builder can sort and filter the related records it lists in a table; and agreement templates accept runtime variables for recipients and documents. A separate template is still the right answer when the approved wording itself differs, for example by jurisdiction, because that is where a single template becomes hard to review.
Text tags are short pieces of formatted text, such as {{Sig_es_:signer1:signature}}, placed in a Word, PDF or other document, which Acrobat Sign converts into real fields when the document is uploaded. They carry the field's role, type and rules: required, read-only, validation, show-if conditions and sender prefill. Use them whenever the same document is sent again and again, and especially when another tool produces it, so every field arrives placed and assigned without anyone dragging fields onto it.
Yes, with calculated fields. Each one has an expression, which Acrobat Sign evaluates at signing, and an optional number, currency or date format; Adobe's own examples include order-form pricing and a contract end date worked out from the term the signer chooses. Calculated fields are part of Advanced forms, which Adobe includes only with multi-license service levels, so we confirm your plan first. Without them, we calculate the value in Salesforce and merge it in as a read-only field.
Mark those fields read-only. Adobe's text tag guide describes read-only fields as the way to merge data into a document so that the signer cannot change it, set with an exclamation-mark prefix or the read-only directive. Fields the signer does complete can carry validation rules for text, numbers, currency, percentages and dates, so what comes back is in a usable format.
For most of them, yes. A web form is published once, shared as a link or embedded in a website, and completed and signed on any device, with counter-signers and copy recipients set on the form. Each submission becomes its own agreement, and the submitted field data can be downloaded as a CSV. Writing that data back into Salesforce records is a mapping question, covered under Adobe Acrobat Sign Salesforce integration.
Not necessarily. Adobe lists both among the document generation apps its Salesforce package works with, so the existing tool can keep producing the document while Acrobat Sign handles signing. Document Builder makes sense when a document is simple enough not to need a separate generation tool. We implement all three, and our Conga document generation and Nintex DocGen pages cover the generation side.
Next Step
Bring one document, we will template it
A first conversation covers the document that costs your team the most time: where its data comes from, how many versions exist, and what signers get wrong. Enough to say which build method fits and what the first template would take. No obligation to proceed.
Talk to a Salesforce architect who builds Adobe Acrobat Sign templates
