Sending waits for someone to remember
The deal reaches the right stage, but the agreement only goes out when a rep opens the record and clicks Send for Signature. On a busy week that is a day lost, and on a bad one it is a deal that cools.
Adobe Acrobat Sign · Workflow Automation
Adobe Acrobat Sign workflow automation that moves agreements without chasing
Adobe Acrobat Sign workflow automation is the set of rules that starts an agreement, routes it to the right approvers and signers in the right order, reminds them, handles delegation and expiry, and updates your systems when it is signed, without anyone pressing a button or sending a chaser. Twopir Consulting designs and builds those rules in Salesforce Flow, the Acrobat Sign managed package and Acrobat Sign's own workflow tools. Fewer manual signing steps, and a process your admins can still change.
12+
500+
250+
40+
Trusted by 500+ organizations — including healthcare, legal and professional-services teams that run their agreements and approvals through Salesforce with Twopir Consulting.
What We Automate With
- Salesforce Partner
- Adobe Acrobat Sign for Salesforce
- Salesforce Flow
- Apex Actions
- Background Actions
- Custom Workflow Designer
- Web Forms
- Batch Agreements
Signing is automated, the process around it is not
Most teams already have e-signature. What they do not have is the process around it: something that decides when an agreement goes out, who sees it first, what happens when nobody responds, and what changes once it is signed. These are the six gaps we are most often asked to close.
Approvals happen in an inbox
Legal or finance approve terms by email before anything is sent, so the approval has no record, no order and no audit trail, and the agreement itself starts only after somebody forwards a "looks fine".
Routing lives in people's heads
Who signs, in what order, and who counter-signs depends on the deal size, the region or the agreement type. Senders retype recipients every time, and the order changes with whoever is sending.
Reminders and expiry left on defaults
Agreements sit unopened because no reminder cadence was set, or they expire on a fixed number of days that has nothing to do with the offer date or the contract start written on the record.
Signed is treated as the finish line
The agreement completes, and then a person updates the stage, creates the onboarding task, tells finance and files the PDF. The signature was automated; everything it should have started was not.
Your automation and the package collide
Custom triggers and old Process Builder logic fire on the same agreement updates the package makes. Adobe documents that queueable jobs chained off its status and mapping updates can fail with a "Too many queueable jobs" error.
Definition
Acrobat Sign automation, defined
Adobe Acrobat Sign workflow automation means designing the rules that start, route, remind and close agreements without manual steps, and building them on the automation surfaces Acrobat Sign supports. In a Salesforce org that is mostly Salesforce Flow calling the Acrobat Sign managed package, plus the package's background actions and data mapping. Outside Salesforce it is Acrobat Sign's Custom Workflow Designer, its web forms, and the Power Automate-based workflows inside the Acrobat Sign web app.
Three parties are involved, and it helps to keep them apart. Adobe builds Acrobat Sign and the Salesforce package, and decides what each automation surface can do; its guide to automating Acrobat Sign with Salesforce flows and its Custom Workflow Designer overview are the reference. Salesforce provides Flow and the record model the automation runs on. Twopir Consulting designs the process and builds it: triggers, routing, reminders, delegation, post-signature updates, exception handling and testing.
This page is about the process, not the plumbing. Installing and connecting the package, agreement objects and merge and data mapping basics are covered under Adobe Acrobat Sign Salesforce integration; templates, text tags and Document Builder under Acrobat Sign document automation and templates; REST API, webhooks and custom code under Acrobat Sign API integration; and Microsoft, HR and ERP connectors under Acrobat Sign integration services. The whole engagement model is on our Adobe Acrobat Sign consulting and implementation page.
Choosing where the automation should live
Acrobat Sign can be automated from more than one place, and each has a different owner, a different audit trail and different limits. The first design decision is which surface owns which step. The rule we start from: if the agreement belongs to a Salesforce record, the automation lives in Salesforce.
| Automation surface | What it can do | Best for | What to know before building |
|---|---|---|---|
| Salesforce Flow · Apex Action | Send, remind, update, cancel or delete an agreement, and load an agreement template with a master record and runtime variables. Works in scheduled flows and accepts several requests per run. | Agreements that start from a record event: a stage, a status, a date, an approval. | Auto-send must run synchronously; auto-send cannot be combined with Acrobat Sign library documents; only parent fields can be referenced; actions that return a value, such as a signing URL, are not available. |
| Background Actions field | Changing the agreement's Background Actions picklist sends, reminds, updates, cancels or deletes in the background, from a Flow Update Records step or any other update. | Simple actions on an agreement that already exists, such as a reminder or a status refresh. | Only actions valid for the agreement's current status run. It cannot load an agreement template; that needs the Apex Action. |
| Custom Workflow Designer | Workflow templates that produce a custom Compose page with predefined participants, roles, routing, messages, documents and identity checks, shared to a user, group or account. | Agreements started in Acrobat Sign itself, where senders must follow a fixed, regulated process. | Supported on Acrobat Sign Solutions and Acrobat Sign for Government, not Acrobat Standard or Pro. Workflows use library templates, and senders can be restricted to sending only through workflows. |
| Web forms | A published form, linked or embedded, that the first signer completes; further signers and counter-signers follow, and submissions export as CSV. | Processes the counterparty starts: applications, requests and registrations. | Each submission creates a separate agreement, so the routing after the first signer is designed into the form. |
| Power Automate workflows in Acrobat Sign | Flows created inside the Acrobat Sign web app from curated templates, AI assistance or from scratch, each with at least one Acrobat Sign connector. | Microsoft 365-centred teams whose agreements do not start in Salesforce. | Adobe's help centre lists a retirement of the embedded Power Automate integration in 2027. We check the current status before designing on it. |
| Batch Agreements | Many agreements from one agreement template and a Salesforce query, from the package's Batch Agreements tab. | The same document to many records at once: annual attestations, policy updates, renewal notices. | A power-user tool. The query, the template and the recipients are tested on a small batch before the full run. |
Six parts of an automated agreement process
A workflow is only as reliable as its weakest step. We design and build each of these in a sandbox, test them against the paths that fail in production, and only then promote them.
Triggered Sending
The agreement goes out when the record says it should, from a record-triggered or scheduled flow calling the package's Apex Action with the right template and master record.
- Entry criteria that stop sends from half-built records
- Template selection by agreement type
- Runtime variables for recipients and documents
- Auto Send, which needs a recipient and a document on the template
- Send on behalf of the record owner where set up
Approvals & Signer Routing
Internal approval and external signature in one agreement, in a fixed order, with each participant given the role that matches what they actually do.
- Signing order set on the template, not by the sender
- Signer, Approver, Acceptor, Form Filler and Certified Recipient roles
- Recipients from Contacts, Leads, Users, Groups or email
- Acrobat Sign groups that control who can send
- Identity checks set per recipient
Reminders, Expiry & Notifications
A reminder cadence and an expiry date that follow the business, so agreements neither sit unopened nor stay open past the date the offer stands.
- Daily, weekly or business-day reminders until signed
- Days until expiration taken from a record field
- Scheduled Flow reminders tied to contract dates
- Chatter updates when agreements are viewed and signed
- Mapping-error emails routed to an owner who acts
Delegation & Replacement
The process keeps moving when the named person is the wrong person, is away, or has left, without cancelling the agreement and starting again.
- Delegator options per role, enabled in Lightning
- Replace Recipient on agreements already in flight
- Rules for who may delegate, and to whom
- Send-on-behalf for automated and Auto Send agreements
Post-Signature Automation
Signature becomes the trigger for the next step: the stage moves, the onboarding starts, finance is told and the signed copy is filed where people look for it.
- Data mapping on signature or at a set workflow stage
- Record-triggered flows on agreement status
- Different paths for signed, declined and expired
- Signed PDF and audit trail filed on the right record
- Handoff to downstream systems where one is needed
Exception Handling & Monitoring
Automation that fails quietly is worse than none. We design what happens when it does, and who finds out.
- Apex Action errors read from the result and logged
- Fault paths that create a task for a named owner
- Review of triggers and legacy Process Builder logic
- Agreement and workflow reports by status
- A runbook for re-sending and recovery
Six agreement workflows, start to finish
Every workflow answers the same three questions: what starts it, how it routes, and what happens once it is signed. Three of these follow scenarios Adobe publishes in its Experience League recipes; the other three are the Salesforce patterns we design most often.
Quote to Signed Contract
The contract goes out when the opportunity reaches the agreed stage, and the opportunity moves on when it comes back signed.
- Starts
- A record-triggered flow on the opportunity stage
- Routes
- Internal approver first, then the customer signer
- On signature
- Data mapping updates the stage and the PO number
Multi-Party Requisition
Adobe's commercial-contracts recipe: a requisition form with calculations, sent through a workflow template so every sender follows the same order.
- Starts
- A sender picks the workflow in Acrobat Sign
- Routes
- Certifying official, requisitioner, approving official
- On signature
- Required CC recipients receive the signed copy
Application with Unknown Co-Signers
Adobe's government loan recipe: the applicant does not know every signer in advance, so the form collects them as it goes.
- Starts
- The applicant opens a web form on a phone
- Routes
- The applicant adds the co-owner, who signs only their section
- On signature
- The loan manager counter-signs to approve
Approval Chain Chosen by the Signer
Adobe's education internship recipe: the student names their own supervisor and department head, so the route differs per application.
- Starts
- A web form on the academic services site
- Routes
- Student, then supervisor, then department head, in order
- On signature
- A copy goes to the administering office automatically
Renewal on a Schedule
Renewal paperwork goes out ahead of the contract end date and keeps reminding until it is signed or the window closes.
- Starts
- A scheduled flow on the contract end date
- Routes
- The account's signer, with reminders until signed
- On signature
- New term dates written back to the contract
Attestations in Bulk
The same acknowledgement to hundreds of contacts, sent from one template and tracked on each person's record.
- Starts
- A Salesforce query in Batch Agreements
- Routes
- One signer per agreement, one agreement per record
- On signature
- Status rolls up so the gaps are visible
Adobe's recipes are published on Experience League and describe Adobe's scenarios, not Twopir client work. Comparing e-signature tools for the same process? See how we approach DocuSign workflow automation.
Where Flow stops and code begins
Most agreement automation is configuration, and we keep it that way because your admins can maintain it. A few documented limits decide when a requirement needs code instead. We name them in design, not mid-build.
| Requirement | What limits the configured route | How we handle it |
|---|---|---|
| Send a library document automatically | The Flow Apex Action does not support auto-send together with Acrobat Sign library documents. | Attach the document to the agreement template or the record instead, or send for review rather than auto-send. |
| Use data from a child or related record | Flow actions can reference only parent fields, and data cannot be mapped to or from a related list. | Put the value on the master record with a lookup or a Flow update before the send. |
| Hand the signer a link, or read agreement details mid-flow | Flow actions that return a value, such as document information or a signing URL, are not supported. | A small Apex class against the package's documented global services, called from Flow. |
| Run your own async jobs after package updates | Queueable jobs chained off the package's status and mapping updates can hit the queueable limit. | Make the dependent step synchronous or scheduled, and retire the trigger or process that collides. |
| Swap a signer on an agreement in flight | Available to users through Replace Recipient; automating it needs Apex. | The package's changeRecipient method, available from version 24.14, with replace or alternate behaviour. |
Flow, templates and workflow settings
Triggered sends, signing order and roles, reminders, expiry from a record date, delegation, data mapping on signature, status-driven next steps and workflow templates in Acrobat Sign.
Built so a Salesforce admin can read it, change it and test it.
Apex, and the API when Salesforce is not the starting point
Value-returning actions, recipient changes in automation, batch processing beyond the Batch Agreements tab, and events that must reach another system. REST and webhook work is covered under Acrobat Sign API integration.
Always against Adobe's documented extension points, never by editing the managed package.
From the process on paper to a workflow that runs
A focused first workflow, one agreement type with one approval path, typically runs a few weeks end to end. What extends a timeline is breadth: more agreement types, more routing variants, and more systems that need to hear about the result.
Map the Process
We trace how each agreement is raised, approved, signed and acted on today, including the email approvals and spreadsheet reminders nobody has written down.
DeliverableCurrent-state map and the steps worth automating
Design the Rules
Triggers, routing, roles, reminder and expiry policy, delegation, post-signature actions and exceptions, with the automation surface chosen for each step.
DeliverableWorkflow design, signed off by the process owner
Build in Sandbox
Flows, templates, mappings and workflow templates built against an Acrobat Sign sandbox environment where your account has one, never directly in production.
DeliverableWorking workflow, demoed to the process owner
Test Every Path
Not just the signature: declines, expiry, delegation, a replaced signer, a reminder cycle, a record that fails entry criteria, and two automations firing at once.
DeliverablePassed test matrix and owner sign-off
Release & Train
Deployed with the old manual steps switched off on the same day, and short training for senders, approvers and the admins who will own it.
DeliverableLive workflow and admin runbook
Monitor & Tune
We watch time to signature, expiries and exceptions after launch, adjust reminders and routing, and recheck after each managed-package upgrade.
DeliverableTuning notes and an upgrade checklist
One agreement stage, fully automated
We do not have a published Adobe Acrobat Sign case study, and we will not dress another tool's results up as one. This engagement used Nintex and PandaDoc. It is here because the workflow design is the same: the agreement starts from the deal stage, status writes back to the record, and nobody chases a signature by hand. Each figure is scoped to that engagement.
Same Architecture
Contracts, offer letters and KYC forms were generated from Salesforce opportunity data the moment a deal reached the document stage, sent for signature, and their status was written back to the opportunity, so managers could see which deals were awaiting signature, signed or stuck. Before, agents copied data into Word templates and sent PDFs by email.
What carries over to Adobe Acrobat Sign The trigger, the routing and the write-back. The signing tool was 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
40% Faster deal closures
250+ Agents and brokers on the platform
Workflow design from Salesforce architects
Agreement automation sits on top of everything else in your org: the flows, triggers, sharing model and integrations that are already there. It works when it is designed as part of that system, not bolted beside it.
We design the process before the flow
Automating today's routing as it stands only makes a confused process faster. We agree who approves what, in which order, and what signed should trigger, and then build it.
We know what the rest of your org is doing
Agreement automation shares records with your existing flows, Apex and validation rules. We review those interactions during the build, which is where collisions such as the queueable limit are caught.
We say where configuration stops
Every Flow limit that affects your design is named up front, with the alternative. You decide on code knowing why it is needed, not because a build hit a wall.
We stay inside the package's supported surface
Flow actions, background actions, documented Apex services and Acrobat Sign workflows. Nothing that edits the managed package, so Adobe's upgrades keep reaching you.
We hand over what we build
A documented workflow your admins can change, and an upgrade checklist. When you want us to stay, Salesforce support and managed services keep the automation tuned.
Acrobat Sign workflow questions, answered plainly
Use the Apex Action when the flow has to create the agreement: it loads an agreement template against a master record, with runtime variables, and can then send it. It also runs in scheduled flows and accepts several requests per run. The Background Actions field suits an agreement that already exists: setting it from a Flow Update Records step sends, reminds, updates, cancels or deletes in the background, but only actions valid for the agreement's current status run. Most designs we build use both.
Usually, yes. An agreement template can take recipients as runtime variables, so a flow passes the right contact, user or email address for each record, and recipients can also come from Salesforce Contacts, Leads, Users or Groups. A separate template is still worth having when the signing order or the roles differ, not just the people. Outside Salesforce, Acrobat Sign workflow templates let senders add recipients inside guardrails the workflow sets.
Yes. From version 21 of the package, Days Until Expiration on an agreement template can reference a field on the master record, such as an expiry date, and reminders can run every day, every week or on business-day cadences until the agreement is signed. For reminders tied to a date, such as a renewal deadline, a scheduled flow can call the package's remind action. One upgrade detail: the business-day reminder values added in version 24.14 have to be added to the picklist by hand on an upgraded org; clean installs already have them.
There are two documented options. Delegator roles, switched on in a custom setting and supported in Lightning, let a recipient pass their role to someone else. Replace Recipient lets a sender swap the person on an agreement already in flight, and from package version 24.14 the changeRecipient Apex method can do the same from automation. We decide in design who may delegate and who may replace, so the audit trail still means something.
When the agreement does not start from a Salesforce record. The Custom Workflow Designer builds workflow templates in Acrobat Sign that fix participants, roles, routing, messages and documents for people sending from Acrobat Sign itself, and an account can restrict senders to workflows only. It is supported on Acrobat Sign Solutions and Acrobat Sign for Government, not on Acrobat Standard or Pro. When the agreement belongs to a Salesforce record we keep the automation in Flow, so the record stays the system of record; Acrobat Sign workflows can also be attached to Salesforce agreement templates when the linked account has them enabled.
Yes. The Acrobat Sign web app includes Power Automate-based workflows: each must contain at least one Acrobat Sign connector, and can start from a curated template, from AI assistance or from scratch. Adobe's help centre also lists a retirement of that embedded Power Automate integration in 2027, so we confirm its status before designing on it. Connecting Acrobat Sign to Microsoft 365, Dynamics 365 and other business systems is covered under Acrobat Sign integration services.
Usually because it is queued behind the package's own asynchronous work. Adobe documents that from version 21 the package runs automatic status updates and data mapping as Queueable Apex, and that a customer queueable job chained off those updates can fail with a "Too many queueable jobs added to queue" error. Adobe's fix is to deactivate the trigger, process or workflow that chains the job, or to make that step synchronous or scheduled. We check every org for this pattern before adding agreement automation.
Next Step
Pick one agreement, we will automate it
A first conversation covers how that agreement starts, who approves and signs it, where it stalls and what should happen once it is signed: enough to say which automation surface fits and what the first workflow would take. No obligation to proceed.
Talk to a Salesforce architect who automates Adobe Acrobat Sign
