Auto-Read Data into Agreement Workflows With Docusign Extension Apps
The world is increasingly moving to an all-digital space, where everything is handled online. Contracts are no longer signed with pen and ink — most processes are completed digitally from start to finish. Even with companies moving completely digital, agreements are still required and they power every business – entire manual workflows are built around creating, committing to, signing, and managing digital contracts.
Docusign is widely known as a trusted e-signature platform, used by millions to create and sign non-disclosure agreements (NDAs), contracts, lease agreements — anything where a pen-and-ink signature used to be required.
However, Docusign has grown beyond its eSignature product roots into a comprehensive agreements platform, also known as Docusign Intelligent Agreement Management (IAM), offering a full-fledged developer ecosystem that helps companies integrate, automate and extend agreements. To help companies extend their solutions beyond their current market, the Docusign platform enables them to publish their apps to the Docusign App Center (to reach over 1.7 million Docusign customers) or privately for specific needs. For example, Glyue is an application that leverages Docusign’s ecosystem, enabling credit unions and banks to build integrations without starting from scratch.
If e-signatures are a common part of your company’s workflows, Docusign Maestro and extension apps may help improve your team’s velocity and success. Maestro can automate workflows, while extension apps can reduce manual effort and potential errors by using information in your existing data stores as input for digital agreement documents.
I’ll explore some ways developers can leverage the Docusign platform by building an example extension app and workflow.
How Automated Intelligent Agreement Management Eases Developer Burden
“The Docusign Platform is really focused on solving the disconnected products problem,” explained Brendyn Alexander, lead product manager at Docusign, in an interview. “$2 trillion is left on the table due to static files, manual and repetitive processes, and disconnected products. Maestro is a core extension point for Extension Apps, one of six or seven different products at Docusign with extensibility built into them.”
He continued, “agreement workflows might integrate a dozen different SaaS [Software as a Service] products, and teams are looking for ways to pull data in and send data out to external products in order to automate their agreement workflows.”
Because extension apps make it easy for developers to build custom, reusable functionality into Docusign’s workflow engine, Alexander explained, it can simplify the integration of your product into Docusign workflows. This, in turn, provides customers (or your own developers) an easy, low-code approach to integrate with Docusign workflows.
“We are enabling a new class of developers: low-code/no-code developers. Professional developers build the extension app, doing the work to glue the products together. Then low-code/no-code developers can construct the logic and user interfaces to incorporate new data flows into end-to-end agreement workflows,“ Alexander clarified.
Publishing an extension app in the Docusign App Center gives all Docusign customers access to an extension and the ability to integrate your service into theirs. Extension apps can also be published privately. Alexander explained. “Docusign Private Extension Apps enable organizations to reuse their proprietary, private data sources securely in Maestro workflows.”
Agreement workflows are built using a “create, commit and manage process. Automation is a horizontal thread that runs underneath all of the steps, and extension apps are a critical part in the automation process,” he said.
For example, imagine your company requires an NDA to be signed before starting the job interview process. This is a high-value, cross-functional workflow that recruiters process daily. Once a candidate has been invited to interview, there is a manual workflow to generate the NDA, collect the signatures and schedule the first meeting. The recruiter must manually check (or wait for an email) to see if the NDA has been completed.
Docusign’s Maestro workflow can help you automate this process by pulling candidate names and details directly from the HR system, generating the NDA and sending it for signature. Then, upon receiving the completed document, it automatically sends an email asking the candidate to provide a preferred meeting time or to choose from available meeting slots.
Now extend this to every workflow that requires a signature — contracts, leases, etc. eliminating manual effort to execute these agreements saves time, money and aggravation, improving business outcomes. The Docusign APIs can autofill your documents and automate the signing workflow, eliminating the headaches of tracking and following up with users, customers or any workflow requiring a digital signature.
Integrating Data with Docusign Extensions
You may be wondering: Where does the data come from in the workflow described above? How does the document get auto-populated? And what happens to any data the customer enters during the document completion process?
Docusign extensions are software packages that enable external applications to interface with Docusign in a safe and secure manner. If your product has customer data that can feed into a contract pipeline, you can build a Docusign extension app to quickly and efficiently connect to Docusign, enabling process builders to create agreement workflows that include your product.
Docusign extensions have the following capabilities:
- Data input/output: Read and write customer data from and to your database, making it available to other workflow steps, such as auto-populating any document requiring a signature. File input/output will become available in Q3 2025, enabling you to move documents between Docusign and external cloud storage or systems of record.
- Data verification: Verify data entered into agreement documents to ensure that it is valid before completing the agreement.
- File archive: Write agreement documents to cloud storage or file analysis services.
Building a Sample Docusign Extension App
Now I’ll show you how to create a sample Docusign extension app to read data from an external data store. The extension app will then be used to build a workflow that creates a document for digital signature from that data.
Developing the Application Infrastructure
The data used when building a Docusign extension app might come from a customer relationship management (CRM) system, a recruiting tool or even an internal database with customer data. To connect your datastore to Docusign securely, clientIds and clientSecrets will be used for authentication of your extension with the datastore. In this example, you’ll use the Docusign Reference Implementation for data IO, which can be found on GitHub.
The README provides step-by-step instructions to deploy a sample database that can interact with your Docusign extension. (In practice, this would be replaced by your internal database or CRM tool.) The steps are:
- Clone the repo.
- Create four secret values and add them to the
example.development.env. Resave this file asdevelopment.env. - Run
npm install. - Run
npm run dev. - Your application is now running locally.
- Follow the instructions in the README to set up and run ngrok to create a forwarding address.
The sample application with customer data is running. In practice, this will be replaced by an enterprise data store.
Now, let’s build a Docusign extension app to connect the sample data store with the Maestro agreement workflow containing an eSignature step.
Building the Extension App
To create a Docusign extension app, sign up for a free developer account on the Docusign Developer Center.
Once you’ve signed up, you can begin creating the extension. There are docs in case you get stuck, but let’s jump right into creating the extension.
The Developer Console is the dashboard where extension app creation begins. Click the “Create App” button to begin creating an application.
Creating an app in the dashboard.
The reference application includes a JSON manifest, so choose “By editing the manifest.”
The definition of your Docusign App extension is inside the JSON manifest. The GitHub repository comes with a sample manifest file that you can use as a framework for your application.
Updating the JSON Manifest
The JSON has several main categories:
- Name, description, icon, screenshots, publisher, regions, distribution, URLs: Information about your extension, links and images. This is more about marketing and public/private distribution of your extension on the Docusign App Center, so you can fill it out as needed.
- Connections: Contains authentication information for connecting Docusign with your system.
- Extensions: A list of the templated actions that are supported in your application and are needed to fulfill an extension type contract.
- Actions: Webhook definitions that will map Docusign UI interactions to your system’s API endpoints.
Let’s fill out the Connections, Extensions and Actions sections of the JSON:
Connections
The GitHub repository tells you how to create a clientId and clientSecret and how to add them to your application’s environmental variables. There are also instructions on creating an ngrok proxy address for your tokenUrl and authorizationUrl. Update the four URL fields in this section.
Extensions
Valid actions used in the extension are listed in the documentation. There is no need to edit this section for the demo, but this is where the extension actions are defined.
Actions
Define all the actions and what the API endpoint is for the action (these will again use the ngrok proxy):
Now that the JSON is updated with the correct parameters, it can be uploaded into the Docusign Developer Console.
Once uploaded, it must be tested for JSON validity. Assuming that the JSON is valid, save the changes.
Validate and save your JSON.
Test Your App
It is now time to test the endpoints of the extension from the Docusign end.
First, install the application:
Choose “install app” to add the app to your Docusign developer account
Once the application is installed, you’ll see authentication and action tests to run:
Tests and actions you can run.
First, test the authentication. The screenshot below shows a successful connection:
Your test succeeded!
The ngrok logs show that there was a successful connection:
Test the Create Record Endpoint
The inputs for these endpoints are in the GitHub README.
After running the CreateRecord test, the created record can be found in the Account.json file in the local copy of the application:
Once your application has passed all the tests, you’re ready to use your Docusign extension that integrates your application with Docusign.
You’ve built the glue — connecting systems, APIs and event triggers. With that groundwork in place, let’s build a low-code/no-code workflow using the new extension to define the logic and user experience.
Build a Simple Maestro Workflow
Before you can begin building a Maestro workflow to streamline your agreement process, ensure you have an account that supports Maestro, then create a workflow by following the official documentation.
You must also install your app in the Docusign App Center and create a connection to the application under the account that has access to Maestro. Then create a connection to the app you built so you can use the connection when configuring the workflow.
Extract Data Using the Extension App
Next, add your extension app step to the workflow. In this case, that’s “Read from Doug Test app”:
Choose the new extension app for the first step in the workflow.
You will read from the Account table:
Connecting the workflow to the data tables from the extension. This will open a search box that constructs a query into the account table.
In this query, the search is looking only for the Account ID equal to 3. This is very specific but could be abstracted in the workflow to a variable defined in an earlier step. The next window specifies what values to retrieve from the search:
Select the fields to include in the response. Extract the Account ID, the Name and the Shipping Latitude from your database.
Collect Signatures
For example, imagine you created a Docusign template that requires three values and a signature:
The next step in the workflow will collect the Signature and fill in the fields retrieved from the extension app in the first step.
The first configuration step is to decide who signs the document. In this case, you’ll hard-code the values in the workflow:
Hard-coded signer can use variables extracted by the extension.
Then, you can map the fields for the eSignature step and the template it’s using to the fields you extracted using the extension app:
Add a Confirmation Screen
Once you’ve finished configuring the eSignature step, it’s a good idea to add a final confirmation screen telling the user that the workflow has completed.
You’re now ready to publish your workflow and run a test!
Running the Workflow
From the Workflow dashboard page, you can run the new workflow by following the official documentation.
This two-step workflow shows how to automate pulling in external data via your new Docusign extension app, then automating the execution of an eSignature agreement using that data.
On the Developer Dashboard, under Maestro Workflows, Click “Start Workflow.”
There are multiple ways a workflow can be started — from an API call via Maestro API (general availability slated for Q3), from a link or directly in the dashboard interface. I’ll demonstrate by using Maestro to build this simple workflow:
The first step runs extremely quickly, and the document signature page appears. The Name, Latitude and ID are automatically filled in from the extension. Upon signing the document, the workflow is completed.
Publish an Extension App
When you create an extension app in the Developer Console, it is only available in your developer account and can only be used in the demo environment. To make it available in production, you must publish it to the Docusign App Center.
You can choose to publish your app as public or private:
- Public apps are listed in the Docusign App Center for all customers to install. This allows you to distribute your extension app to a large audience of Docusign users. To publish a public app, you need to be a Docusign partner.
- Private apps are designed for businesses with specific needs, such as integrating proprietary or internal systems, or in any case where the developer does not wish to make the extension app available for all Docusign customers.
Regardless of distribution type, all apps must follow App Center publishing guidelines and pass Docusign’s review process to ensure compliance with security and functionality standards. Once approved, public apps go live in the App Center for all customers, while private apps must be shared with specific production accounts to be available to them.
Summary
Docusign is more than just an eSignature provider. Under the hood of Docusign’s Intelligent Agreement Management platform capabilities is a full developer suite of APIs and tools allowing developers to build extensions that connect external applications and data stores to Docusign.
This article walked through the steps of building a simple Docusign extension app. It utilized Docusign’s Maestro Workflow engine to create a document workflow using that extension app, including signing a document pre-populated with data extracted from your extension app’s data store.
These tools provide a lot of power for developers, helping to automate and streamline agreement processes. If you’d like to learn more about Docusign for Developers, check out the public announcement, read the docs and then get started for free! If you have questions, join the Docusign Developer Community for help and support.
