Hi everyone!

I’m looking forward to your questions and diving into the world of building and automating agreement workflows! 🚀

Here are some helpful resources on the topic to kick things off:

• Secure, verify, comply: Automate identity checks with Docusign APIs
• How to trigger a Maestro workflow
• Workflows Sample App

2 questions - Authentication - is this Docusign authentication or can this be linked with SSO type authentication?  Can data be passed through from from IDM/Authenticaton?  if not what other systems?

Hi ​@Norma Clark! Maestro uses OAuth 2.0 for authentication. Check this resource out for more information on authentication. At the account level, Docusign can integrate with your SSO for user login, but Maestro does not automatically pass identity data from your IDM/Authentication into workflows. If you need to use attributes from your IDM system (like email, employee ID, or group), you can capture those after login and pass them into Maestro as workflow input variables. Maestro can also accept data from systems like CLM, Power Automate, or an extension app via the Maestro API. This is a helpful resource that will provide more information on passing data to workflow variables.

Thanks for your question!

​@niani.byrd 

When triggering Maestro workflows from our app, what’s the best way to avoid duplicate runs and keep track of which workflow belongs to which user action?

For example, should we use webhooks or polling to check status, and what’s the best way to pass a correlation ID so we can safely retry if something fails?

Hey there ​@Vas! 

To avoid duplicate workflow runs, generate a correlation ID for each user action (for example, order-1234) and include it as a starting variable when triggering the Maestro workflow. Store a local mapping of {correlationId → workflowInstanceId} in your database, so that if a retry occurs, you can check whether a workflow has already been created for that action. Check out more information here on starting variables.

For tracking status, webhooks through Docusign Connect are the recommended approach over polling. Subscribing to workflow events such as workflow-started or workflow-completed will give you real-time updates, and Connect will handle delivery and automatic retries to ensure those updates reach your system. Here’s a helpful resource on monitoring workflows.

Great question!

​@niani.byrd Hey there! I was wondering if DocuSign provides the ability for programmatically signing a document (via an API, maybe). The scenario is that we have a contract that needs to be signed on behalf of our company as well as by the client who receives the contract. It would be great if we could automate the signing on our behalf and just send it to the recipient for signing. Is this possible? If not, are there any alternatives? Thanks!

Hi ​@faheemkodi!

Unfortunately, automatic signing of a document through the API is not possible in Docusign because each signature requires a signer to complete the signing ceremony. If your company is required to sign, one option is to use a Docusign electronic seal (eSeal), which can be applied programmatically to certify the document on behalf of the organization. Here’s a technical blog that goes into deeper detail on using a Docusign eSeal for your documents. If an eSeal is not appropriate, you can prepopulate fields with your company’s information before sending. This does not eliminate the need for a company signature, but it does simplify the process by reducing what must be filled in manually before the envelope is signed and routed to the client.

Thanks for your question!

Hi ​@niani.byrd, I have one, possibly two, questions: What resilience patterns does Maestro support or recommend for transient downstream failures (retry, circuit breaker, backoff, DLQs), and how should those parameters be scoped per step vs. platform-wide defaults?

Hi, I’m working on an integration between Make.com and DocuSign.

In my scenario, I already have everything set up (Google Sheets → Google Drive → Google Docs → DocuSign). The last step is where I’m stuck:

I want to use a DocuSign template for the recipient roles and signing fields, but instead of using the template’s default document, I’d like to replace that document with another one (a lease generated earlier in the flow).

Can you help me figure out how to set this up in Make.com? Also, please let me know if I should explain my setup in more detail.

Hey ​@Pau123!

Maestro performs internal retries within most step implementations to help handle transient issues, and when a step surfaces an error it has typically already retried multiple times behind the scenes. Building on this, a new capability is coming in the next few months that will let users manually retry an instance from a particular step, giving you more direct control over recovery without having to restart the entire workflow. While Maestro does not include automated patterns like circuit breakers or dead-letter queues today, it does provide tools to pause, resume, and check the status of workflow instances. In addition, Docusign currently provides a retry mechanism today through Docusign Connect, which automatically retries webhook delivery until your system acknowledges receipt. This Connect retry capability is separate from Maestro itself, but together they ensure both workflow execution and event notifications are handled reliably. To support resiliency at the workflow design level, you can incorporate escalation or fallback branches so that when retries are exhausted, the process is routed to either manual intervention or a defined error-handling path.

Good question! 💡

Hey there ​@Yoel!

For third-party automation tools like Make.com, I can refer you to their official documentation for detailed setup instructions. I’m sorry I can’t provide more direct support on this since Make.com is outside of Docusign, but you can find more information here: https://apps.make.com/docusign.

Thanks for your question!

When evolving a workflow from v1 to v2, what’s your playbook for migrating in-flight runs safely, rolling back if needed, and keeping a clear and accessible audit trail of which version handled each agreement? Thank you, ​@niani.byrd! 

Hi ​@PTdev!

It is not possible to migrate in-flight runs to a new workflow version. Existing runs will always continue on the version they started with, and each time you publish an updated iteration of the workflow, Maestro will automatically increment the version number (for example, v1.0.0 → v2.0.0 → v3.0.0). Any new runs started after publication are automatically tied to the newly published version. Once a newer version is deployed, workflow instances cannot be routed back to an older version. You can find more info on workflow versioning here! Additionally, Maestro records the workflow version number for each run, which you can retrieve through the API and store with your agreement metadata for a clear audit trail. For more details on how workflow versioning is captured, check out the Maestro API Reference. The WorkflowInstanceManagement resource specifies where version information is included in the metadata response.

Great question! 🚀

That’s a wrap! 🎉 Thanks to everyone who participated in our async AMA. We loved seeing your questions and hope ​@niani.byrd’s answers helped you out.

🔒 This thread is now closed to new comments, but you can still read through the Q&A anytime.

🎁 ​@Yoel you were the winner of the giveaway drawing! Keep an eye on your inbox tomorrow for a link to claim your gift. 

Thanks again, everyone, for participating and for being part of the Docusign Community! If you think of new questions, feel free to start a post in the developer forum.