Docusign Workflow Builder shows you that a run happened and where it is in the flow, but it does not show you the inbound webhook body that triggered the run. The Monitoring workflows guide and the getWorkflowInstance reference describe instance status and step progress, with no field for the raw HTTP request that started the workflow. To get true docusign workflow builder payload visibility you need a relay layer that stores the inbound payload before it is forwarded. Baton does this in its Action log, recording the verified body, source headers, and the exact parameters that were passed into the workflow.

Why doesn't Docusign Workflow Builder show the inbound webhook payload? #

Workflow Builder is a workflow engine. Its job is to run steps deterministically once a workflow instance starts. Everything it exposes is downstream of that start event: which steps have completed, which step is current, which envelope IDs were created, and the values of the workflow parameters at the time the instance was created. The getWorkflowInstance API is shaped around that lifecycle.

The thing it cannot show you is the inbound HTTP request that produced those parameter values. By the time Workflow Builder is involved, the request has already been parsed and transformed into a parameter map. The original headers, the original body, the timestamp the request arrived, the signature your relay verified - none of that is part of the workflow instance. It lives at whatever layer received the webhook.

That layer is the missing observability surface. Compare it to GitHub's webhook deliveries view, where you can open any recent delivery and see the request headers, the JSON body, the response from your server, and whether it was a redelivery. Most production engineers expect that pane. Workflow Builder does not include one because the inbound webhook is not the workflow engine's responsibility.

The three questions every on-call engineer asks #

At 2am, when a customer pings you that their counter-signed contract never showed up, you are not asking philosophical questions. You are asking three concrete ones.

  1. Did the source platform actually send us a webhook? If HubSpot's deal stage moved but no request was recorded on our side, the failure is upstream of the workflow.
  2. If a webhook arrived, what did it contain? Specifically: was the signer email present, was the contract value above the auto-route threshold, did the custom field for region map to a known value?
  3. If the payload was good, did the workflow we expected actually start with the right parameters? A run that started against the wrong template, or with a stale parameter, looks identical to a successful run until somebody reads the envelope.

Workflow Builder can answer the third question on its own. It cannot answer the first two. That is where the audit gap lives, and where a relay's logs become the source of truth.

What Baton's Action log captures (and what it doesn't) #

Baton sits between the source platform and Docusign. The source platform (HubSpot, Salesforce, Greenhouse, Coupa, Zoho, and so on) posts a webhook to a Baton URL. Baton verifies the HMAC signature, matches the payload fields to the Workflow Builder workflow's parameter names, and triggers the workflow. Every step of that pipeline writes to the Action log.

For each inbound webhook, the Action log records:

  • The raw request body, exactly as the source platform sent it.
  • The source headers, including the signature header used for HMAC verification.
  • The HMAC verification outcome (passed, failed, missing secret).
  • The Workflow Builder workflow the request was matched to.
  • The resolved parameter map - which payload fields became which workflow parameters.
  • The Workflow Builder API response, including the workflow instance ID returned on success.
  • Timestamps for receive, verify, and trigger steps.

What the Action log does not contain:

  • Anything past the trigger boundary. Once Workflow Builder owns the run, envelope-level events live in Workflow Builder and in Docusign Connect, not in Baton.
  • Outbound write-backs to the source platform. Baton does not push signed documents or status back to HubSpot or Salesforce, so there is nothing of that shape to log.
  • A user-configurable field mapping. Baton matches payload field names to parameter names automatically; there is no JSONPath UI to inspect because there are no per-customer mapping rules to inspect.

Tracing one envelope back to one inbound webhook #

The end-to-end trace usually starts from a Docusign envelope and walks backwards. The chain is: envelope ID → workflow instance ID → Baton Action log entry → original source webhook.

A worked example. A RevOps engineer gets a complaint that a deal worth $48,000 was sent to the wrong approver. They have the envelope ID from Docusign.

Step 1. In Workflow Builder, look up the workflow instance that created that envelope. The instance metadata, surfaced via the getWorkflowInstance API or the Workflow Builder UI, includes the parameter values used. You will see, for example, dealAmount=48000 and region=EMEA.

Step 2. Take the workflow instance ID into Baton's Action log and find the inbound Action that produced it. The Action log row points at that instance ID.

Step 3. Open the Action and read the raw inbound body. You can now see whether region=EMEA is what HubSpot actually sent, or whether Baton derived it from a different field. If the inbound body says region=EU and the workflow received region=EMEA, the mapping is wrong upstream of Baton. If the inbound body says region=EMEA and the workflow received region=EMEA, the routing rule inside Workflow Builder is wrong.

// Action log entry, abbreviated
{
  "action_id": "act_8f3...",
  "received_at": "2026-05-04T09:13:22Z",
  "source": "hubspot",
  "hmac": "verified",
  "raw_body": {
    "objectType": "DEAL",
    "propertyName": "dealstage",
    "propertyValue": "contractsent",
    "properties": {
      "amount": "48000",
      "region": "EMEA",
      "signer_email": "buyer@example.com"
    }
  },
  "workflow": "order-form-emea",
  "parameters_forwarded": {
    "dealAmount": 48000,
    "region": "EMEA",
    "signerEmail": "buyer@example.com"
  },
  "workflow_instance_id": "wfi_a12..."
}

With both ends of the trace visible, you stop guessing. The Action log makes the question "what triggered this envelope" answerable in seconds, instead of via an email thread with HubSpot admins.

Spotting payload drift after a CRM schema change #

A failure mode that almost always shows up in audit gaps: payload drift. A CRM admin renames a custom field. They do not tell the integrations team. New webhooks start arriving with a missing or empty field. The workflow runs, but with default or null values.

Without payload visibility, this is silent. The Workflow Builder run looks successful - it accepted the trigger, hit its steps, and emitted an envelope. The envelope just happens to use the default region or the default approver. Days later, somebody notices a pattern.

With payload visibility you can detect drift the first time it happens:

  • Filter the Action log by source and time window. Look for inbound payloads that suddenly miss a previously present field, or where the parameters_forwarded map contains nulls in places that were always populated.
  • Diff a recent payload against last week's known-good payload. Schema changes show up as added or removed keys.
  • Watch HMAC verification status. A common admin reflex when an integration breaks is to rotate the webhook secret, which produces a sudden run of hmac=failed entries that would otherwise be invisible to the workflow team.

If you are debugging this class of failure, our deeper write-up on why Docusign webhooks fail silently covers the failure modes and how to catch them before the customer does. The same principle applies to source-side webhooks: you cannot fix what you cannot see.

When to escalate from Baton's Action log to Docusign Connect logs #

Baton's Action log answers "what came in and what was triggered." It is the right tool when the question is about the inbound webhook or the workflow trigger call. It is the wrong tool when the question is about an envelope event that did or did not fire downstream.

Use Docusign Connect and its failure log when:

  • The workflow ran and created an envelope, but your downstream system never received the envelope-completed event.
  • You suspect a Connect listener is returning a non-200 response and Docusign has stopped retrying.
  • You want to inspect or replay a specific envelope event.

Docusign's troubleshooting Connect guide walks through enabling Connect logging under Settings > Connect > Logs, where the most recent 100 logs are kept. There is also a Connect failure logs API for programmatic retry of failed deliveries.

The rule of thumb:

  • Inbound to Workflow Builder (source platform → Baton → workflow trigger): look at Baton's Action log.
  • Outbound from Docusign (envelope event → your listener): look at Connect logs.
  • Workflow internals (step ran, step failed, conditional took wrong branch): look at the Workflow Builder run view.

Three logs, three failure domains. The mistake teams make is trying to debug an inbound trigger problem in Connect logs, where the data simply does not exist.

Wire this into your runbook #

If you only take one thing away: when a Docusign Workflow Builder run produces a surprising envelope, the question to ask first is "what payload triggered this?" That question has no answer inside Workflow Builder itself. It has an answer at the relay layer, and Baton's Action log is built to give it to you with one click from the workflow instance.

To wire this up for your team, start with Baton and connect your source platforms to your Workflow Builder workflows. If you want broader context on how this fits into a Docusign IAM rollout, the fluidlabs team implements these patterns end-to-end in production.