The question almost every Salesforce admin asks once Docusign IAM lands in the org: "opportunity moves to Closed Won, I need a Docusign Workflow Builder run to fire. How do I wire that up cleanly?"

There are three real answers, and they are not interchangeable. The Docusign managed package is great at sending envelopes but is not a Workflow Builder trigger. Salesforce Flow can call the Workflow Builder API directly, which is the closest thing to a one-click solution but exposes you to Salesforce's synchronous callout limits. A purpose-built relay sits in between and handles the messy parts. This article walks through all three with code, and helps you pick the right one for your volume and reliability bar.

If you want background on the Workflow Builder primitive itself before going further, our complete Workflow Builder guide covers trigger types and the data model.

What "trigger a workflow" actually means in Workflow Builder

Docusign's developer blog is explicit about the supported entry points: Workflows can be initiated via APIs, Connect webhook event triggers, or natively through Power Automate. For Salesforce as a source, the relevant path is the API trigger.

At design time you pick an API trigger on the workflow and define a trigger_input_schema (the typed fields the workflow expects, like opportunity_id, customer_email, contract_value). When you publish, Docusign exposes the workflow as an HTTP endpoint. The Docusign blog announcing the new Workflow Builder API endpoints shows the response shape, including a trigger_event_type: "HTTP" and a trigger_http_config object with the URL and method.

Firing the workflow is then a POST to that URL with the inputs in the body. The response includes an instance_id you can use to check status, as walked through in The New Stack's API-driven Workflow Builder tutorial and the official How to trigger a Workflow doc.

Key takeaway: "trigger from Salesforce" reduces to "call this HTTP endpoint with a bearer token and a JSON body of typed primitives, when an event happens in Salesforce." The interesting question is who in your stack is responsible for that call.

Option A: Docusign for Salesforce managed package + Apex Toolkit

The Docusign eSignature for Salesforce managed package ships an Apex Toolkit - a set of managed Apex classes that let you build, send and track envelopes from Salesforce code.

This is the path most teams default to because it is already installed. It is also the wrong path if your goal is to start a Workflow Builder run.

The Apex Toolkit is envelope-shaped. You compose an envelope, add documents, set recipients, send. It does not surface a triggerWorkflow method. If your "workflow" is really "send one envelope based on Salesforce data," the managed package is the simplest answer. If your workflow has multiple steps, branching, parallel approvers, document generation, or any logic that lives in Workflow Builder, the Apex Toolkit cannot start that workflow for you. You'd be reaching around it to call the Workflow Builder API anyway.

Use this option only when:

• The downstream agreement is a single envelope.
• All routing logic can live inside the envelope (templates, recipient roles).
• You don't need Workflow Builder steps like document generation, conditional branches, or human-in-the-loop approvals.

For anything else, keep reading.

Option B: Salesforce Flow + HTTP Callout

Since 2023 Salesforce Flow has supported HTTP Callout actions, letting admins call external REST APIs from a record-triggered flow without writing Apex. This is the obvious next move: bind a flow to Opportunity stage = Closed Won, register the Workflow Builder trigger URL as an external service, POST the inputs.

A simplified shape:

This works. We've shipped it. It also has three sharp edges that nobody warns you about until production.

1. The 5-second / 10 concurrent long-running Apex limit. Salesforce enforces an org-wide ceiling: no more than 10 synchronous transactions running longer than 5 seconds at once. Salesforce's own engineering team has been warning about this since 2015. Docusign API latency is normally fine, but during incidents or peak load you can blow through 5 seconds, and once you do it counts against the org's concurrency pool, not just your flow's. The first time a Docusign hiccup also blocks the rep from saving a case, you learn this rule.

2. Auth lives in Salesforce. You'll wire a Named Credential to a Docusign-issued JWT or OAuth token. That means token rotation, scoped permissions, and refresh logic become a Salesforce admin problem, not an integration problem. If you have ten orgs across business units, you have ten places to manage credentials.

3. Retries are your problem. Flow's HTTP Callout is fire-and-forget. If the call fails (timeout, 5xx, transient Docusign error), the flow just errors. There's no built-in exponential backoff, no dead-letter queue, no "replay this run later." You can build it, with platform events and queued Apex, but now you're maintaining a queue, and the simple Flow has become an integration project.

For low-volume, low-stakes workflows (think: under a few hundred runs a day, internal NDAs, no SLA on signature time), Option B is fine. Past that, you graduate.

Option C: Webhook relay (Baton)

The pattern that scales is to have Salesforce emit an event - a platform event, an outbound message, a record-triggered flow that POSTs to a relay URL - and let a purpose-built relay translate that into the Workflow Builder API call.

This is exactly what Baton does. Salesforce calls one stable webhook URL on stage change. Baton verifies the source, maps the payload to the workflow's trigger_input_schema, calls the Workflow Builder API, retries on failure with exponential backoff, deduplicates by event ID, and writes a complete audit log of every relay attempt.

What you stop owning when you put a relay in the middle:

• Token management. Docusign credentials live in the relay, not in every Salesforce org.
• Retry policy. Transient 5xx and rate-limit errors are retried automatically. The Salesforce side just sees a 200.
• Idempotency. If the same Salesforce event fires twice (and on busy orgs it does), the relay collapses duplicates so you don't get two contracts in motion.
• Concurrency back-pressure. A relay can absorb a burst that would have starved Salesforce's long-running Apex pool.
• Observability. One place to look when "the contract didn't go out" instead of three.

For a deeper walkthrough of relay-based triggering across platforms, see How to Trigger Workflow Builder from any platform and our broader Salesforce + Docusign integration guide.

A worked example: Closed Won opportunity to NDA + MSA workflow

Here's the same scenario built end-to-end with Option C, to make the shape concrete.

1. Workflow Builder side. Define the workflow with an API trigger. Schema:

Keep these as flat, typed values that match trigger_input_schema. The workflow uses region to pick the right MSA template, and contract_value to decide whether to add a CFO approval step.

2. Salesforce side. Record-triggered flow on Opportunity:

3. Relay side. Validates the source, maps the event to the workflow's input schema, calls the Workflow Builder trigger URL, persists the instance_id so the next signed-and-completed event from Docusign can be tied back to the originating opportunity.

Because the Salesforce flow only talks to a relay it owns, you control the contract. A schema change in Workflow Builder is a relay deploy, not a managed-package emergency.

Authentication and HMAC: the boring part that breaks production

Two auth boundaries to get right:

Salesforce to relay. Treat the relay endpoint as untrusted. Use a shared secret in a header, or better, sign each request with HMAC. The relay rejects anything unsigned. Salesforce does not give you anti-replay out of the box, so include an event_id and have the relay deduplicate.

Docusign to relay (the return path). When the workflow completes, Docusign Connect can POST a webhook back to your systems. Docusign Connect supports HMAC signature verification and you should turn it on. Verify the signature on every inbound delivery. Without it, anyone who guesses your callback URL can submit a fake "contract signed" event, and your Salesforce opportunity gets marked as paid.

For a complete pattern around the inbound side, including duplicate handling and the retries Docusign Connect actually performs, the Baton resources blog goes deep on payload anatomy and silent-failure modes.

Decision matrix

Need	Best option
Send a single envelope on a record event, no multi-step logic	Option A (Apex Toolkit)
Workflow Builder run, low volume, internal-only, you own retry yourself	Option B (Flow HTTP Callout)
Workflow Builder run, customer-facing, any SLA, multiple Salesforce orgs, audit requirement	Option C (relay)

Common mistakes we see

• Treating the managed package as a workflow trigger. It isn't. It's an envelope sender. If your design needs Workflow Builder, plan to call the API.
• Putting the bearer token in a Custom Setting. It will rotate, it will expire, and someone will check it into version control.
• Skipping idempotency. Salesforce flows fire on retries and on bulk updates. Without an event_id deduped at the relay, you will create duplicate workflow instances. The first time is funny. The third time is a customer email.
• Using a synchronous Flow callout for high-volume orgs. Once you cross a few hundred fires per hour during peak, the long-running Apex ceiling becomes load-bearing. Move to async.

The opinionated take

If the entirety of your agreement automation is one envelope per opportunity, the Apex Toolkit is fine and you can stop reading. If Workflow Builder is in your architecture at all, the relay pattern is what scales, and trying to recreate it inside Salesforce Flow is a project that quietly grows until it owns a sprint a quarter forever. Pick the relay early; you'll spend the saved time on the workflow itself.