Salesforce + Docusign is one of the most common CRM-to-agreement integrations in the world. But the native Docusign for Salesforce managed package is built for a human to click "Send with Docusign" on an opportunity. If you want the contract to fire automatically the moment an opportunity closes - no human in the loop - you need a different pattern. This guide covers that pattern, honestly framed around what Baton supports today.

What you'll need #

  • A Salesforce org on Enterprise, Unlimited, Performance, or Developer edition - any edition with Workflow Rules or Flow Builder access that can fire Outbound Messages or Platform Events.
  • A Docusign account with IAM and Workflow Builder enabled.
  • A Baton account.

Two ways Salesforce sends events outward #

Outbound Messages. The older, no-code path. Configured on a Workflow Rule (or Flow), Salesforce HTTP POSTs a SOAP message to a URL you provide. Synchronous, limited per org, but trivially easy to configure. This is the path Baton's Salesforce integration is currently scaffolded around.

Platform Events. Event-driven, async, pub/sub. You define an event object (e.g. Deal_Closed__e), publish it from Flow or Apex, and subscribed consumers receive it over the Streaming API or PubSub API. Platform Events are the modern choice for high-volume orgs.

Both patterns ultimately POST to a URL. Baton gives you a URL. The rest is Salesforce configuration.

Step 1 - Add the automation in Baton #

In the Baton Command Center, open Flow Builder and click + Add Automation. Select Salesforce as the source platform. Pick the target Docusign Workflow Builder workflow from the dropdown - synced automatically from your Docusign connection via the Workflow Checker.

Baton generates a unique, UUID-tokenized webhook URL:

https://app.iambaton.com/hook/c4d9f2a1e8b3

For Salesforce's current Baton support, the verification method is Basic Authentication. Set the credentials in the Webhook Secret fields in the Edit Automation panel. Salesforce will send those credentials as an Authorization: Basic ... header on every message.

Copy the webhook URL for the next step.

Step 2 - Configure Salesforce to POST to Baton #

Option A: Outbound Message (recommended for first setup).

In Salesforce Setup, navigate to Outbound Messages → New Outbound Message.

  • Object: Opportunity
  • Endpoint URL: the Baton URL from Step 1
  • Send Session ID: unchecked (Baton uses Basic Auth, not the Salesforce session)
  • Fields to send: include at minimum any field whose name matches a parameter your Docusign workflow declares (see Step 3)

Save. Then create a Workflow Rule (or Flow) on Opportunity that fires the Outbound Message when StageName = Closed Won (or your chosen trigger).

Option B: Platform Event.

Define a Platform Event (Deal_Closed__e) in Setup. Create a Record-Triggered Flow on Opportunity that publishes an instance of the event when the stage changes. Route the event to Baton by configuring a webhook subscription on the event in Salesforce, or by publishing from a Flow that calls an HTTP Callout to the Baton URL.

Either way, the target is the same Baton webhook URL.

Step 3 - How Baton matches fields #

There is no drag-and-drop field mapping step in Baton. Instead, Baton relies on the parameter contract your Docusign Workflow Builder workflow declares. When you build a Workflow Builder workflow, its start trigger specifies named, typed parameters (e.g. objectId STRING, accountId STRING, amount STRING). Baton's Workflow Checker syncs that contract.

At runtime, Baton scans the Salesforce webhook payload and matches by name. A Salesforce Outbound Message that contains <Id>006xx0000001AAA</Id> will match a Docusign parameter named Id automatically.

If you want a different field layout, you design the Docusign workflow to expect different parameter names. The extraction is configured on the Docusign side, not in Baton.

Step 4 - Test end-to-end #

Move a test opportunity to Closed Won (or whatever trigger you configured).

Within a few seconds:

  1. Salesforce fires the Outbound Message or Platform Event
  2. Baton receives the POST, verifies the Basic Auth header
  3. Baton matches payload fields to the Workflow Builder parameter contract
  4. Baton fires the Maestro API trigger

In the Baton Flow Builder, click Logs on the Salesforce automation card. The Action log shows:

  1. Webhook verification → Verified
  2. Maestro Trigger → Launched - with the Maestro Instance ID linking directly into Docusign

If it fails, the Action log shows where: verification_failed (Basic Auth mismatch), validation_error (payload didn't contain the expected parameter names), or upstream_error (Docusign API issue - retried with exponential backoff).

Why not use Flow's HTTP Callout directly to Docusign? #

Salesforce Flow does support HTTP Callouts without Apex, and in theory you could call Docusign's Maestro API directly from Flow. Three reasons teams don't:

  1. Authentication. Docusign Maestro's API requires OAuth JWT grants for server-to-server use. Flow's callout framework can handle Named Credentials, but maintaining the JWT/refresh plumbing in Salesforce is operationally awkward. Baton owns the Docusign OAuth session (refreshed every 5 minutes) so you don't.
  2. Retries. Flow callouts have no built-in retry policy. A transient Docusign error and the opportunity has no contract. Baton retries upstream_error with exponential backoff and surfaces persistent failures as Automation Failed notifications.
  3. Visibility. Callout failures in Flow are buried. Baton's Action log shows every verify + route attempt, and the Flow Builder surfaces live counts of completed / failed / in-progress per automation.

Observability #

Every Action logs:

  • Salesforce payload received (under "View Payload" - the full raw message)
  • Basic Auth verification result
  • Docusign API request + response
  • Maestro Instance ID with direct-open link into Docusign
  • End state

Failures route to the Notifications Inbox and, optionally, a Slack channel.

Closing thought #

Salesforce gives you a dozen ways to fire a webhook. What Baton adds is the half of the story Salesforce-native tooling doesn't: verified receipt, reliable Docusign triggering, and a single page that shows every Salesforce → Docusign run across your org. If you'd like to be an early-access design partner for Baton's Salesforce integration, book a demo.