> You are reading the Docusign Developer Documentation. For clean Markdown of any page, append .md to the page URL. > > Documentation indexes by section: > - APIs and SDKs: https://docusign.docs.buildwithfern.com/docs/llms.txt > - Platform 101: https://docusign.docs.buildwithfern.com/platform/llms.txt > - Extension Apps: https://docusign.docs.buildwithfern.com/extension-apps/llms.txt > - Docusign CLI: https://docusign.docs.buildwithfern.com/docusign-cli/llms.txt > > Authentication (OAuth, JWT Grant, M2M): https://docusign.docs.buildwithfern.com/platform/auth > Webhooks and Connect: https://docusign.docs.buildwithfern.com/platform/webhooks > > OpenAPI specifications: https://docusign.docs.buildwithfern.com/openapi.json > MCP server: https://docusign.docs.buildwithfern.com/_mcp/server # Workflows > Learn about the workflow objects at the core of the Workflow Builder API. A Workflow Builder workflow is an object that represents your end-to-end agreement workflow, including all pre and post-signing [Steps](/docs/workflow-builder-api/workflow-builder101/steps). You can add and order steps as necessary for your workflow and add conditional logic to create branches within that workflow. Workflows are made up of a sequence of [step](/docs/workflow-builder-api/workflow-builder101/steps) objects. Each step object contains the information and logic necessary for a single operation within your workflow, such as: * Getting participant data via web forms to populate variables used by subsequent steps * Requesting a signature * Saving information to a database or archiving it to the cloud See [Steps](/docs/workflow-builder-api/workflow-builder101/steps) for details. When you’ve finished creating your workflow, you can [publish](/docs/workflow-builder-api/publishing-go-live) it to make it available for other users in your account to view and run, as well as making it usable by your apps in the production environment. See [Publishing and Go-Live](/docs/workflow-builder-api/publishing-go-live) for details. ![Screenshot of an example workflow](/_fern-files/_img/fa7f1c02d0f57e863845ee67227fb529fe5c20a365199fedf3a4c977122b48de.webp) ## Running workflows You can configure how your workflow is triggered by setting a start method. Each Start method surfaces shortcuts such as a link button that helps you configure and use your workflow more easily, or prompts you to define variables that must be populated before the workflow can be started via API. The start method that you select determines how a workflow can be triggered. Each method corresponds to a specific HTTP trigger type. For example, workflows configured to start **From an API** **call** use the `POST` method and can only be triggered through the Workflow Builder API. Workflows set to start **From a link** use the `GET` method and can only be started when someone opens the published trigger URL in a browser. Because of these differences, changing a workflow’s start method affects which trigger methods will continue to work. The following start methods are currently supported in Workflow Builder: | Start method | Trigger type | Description | | -------------------------------- | ------------ | ------------------------------------------------------------------------------------------------- | | **From a link** | `GET` | Starts a workflow when a user clicks a browser link. | | **From within Workflow Builder** | `POST` | Initiated manually from within the Workflow Builder application. | | **From an event** | `GET` | Triggered automatically by a system or event. | | **From a CLM workflow** | `POST` | Initiated from a CLM workflow. | | **From an API call** | `POST` | Supports both **Human** and **Automated Process** triggers. Required for API-triggered workflows. | **Note:** Only workflows configured with the **From an API call** start method can be triggered using the `POST` endpoint. Attempting to start a workflow with any other method will return an error. You can trigger and run a workflow from the Workflow Builder workflow designer UI or by opening a trigger URL: * **Using the trigger URL as a link:** The trigger URL leads to an unauthenticated endpoint that can be used by non-developers. You can open the published workflow’s unique trigger URL in your browser, embed it in a website, or provide it to your participants to enable them to run the workflow themselves. When this URL is accessed, a new instance of the workflow will be executed. You can get the URL: * In the [Workflow Designer](https://apps-d.docusign.com/send/workflows/) by finding the row with the workflow you want to run that is configured to be started via link, then selecting the link icon to copy the URL. You can then embed the link in a page or email that you share with a user. This is typically used by self-service workflows, allowing participants to initiate workflows whenever they need to. * By making a POST call to the [Workflows: triggerWorkflow](/docs/workflow-builder-api/reference/workflowbuilder/workflows/triggerworkflow) Workflow Builder API endpoint. The trigger URL value will be returned in the call response. See [How to trigger a Workflow Builder workflow](/docs/workflow-builder-api/how-to/trigger-workflow) for a full walkthrough. Or from within Docusign: * **Using the Workflow Builder UI** by a user within your organization by selecting the **Run Workflow** button next to the listed workflow. This enables the person who starts the workflow to specify the identities of the workflow participants, such as their names and emails before inviting them. This option is designed to be triggered from within Docusign, rather than externally * **Using a CLM workflow**. This option lets you trigger your Workflow Builder workflow from within a CLM workflow, enabling you to use CLM options such as WhatsApp delivery or SMS delivery alongside Workflow Builder in a single automated process. This option is designed to be triggered from within Docusign, rather than externally. See [Workflow start methods](https://support.docusign.com/s/document-item?language=en_US\&bundleId=yff1696971835267\&topicId=ztb1727892686033.html) for details on each option. After a workflow is triggered, a new *instance* of that workflow will be created. A workflow instance is created for a specific set of participants and holds the data for their agreement process. You can monitor the progress of any instances of a particular workflow using [Docusign Connect](/platform/webhooks/connect). See [Monitor a workflow](/docs/workflow-builder-api/workflow-builder101/monitor-workflow) for details. The following example workflow definition shows the structure of a basic rental agreement workflow. It includes steps to collect information using web forms, send a notification, request a signature, and show confirmation screens. #### Example workflow JSON definition ```json { "id": "47a0367b-xxxx-xxxx-xxxx-5eceefed344d", "name": "Example workflow", "account_id": "08b4799a-xxxx-xxxx-xxxx-b5b4b8a97604", "status": "inactive", "metadata": { "created_at": "2024-01-09T21:23:28.564+00:00", "created_by": "464f7988-xxxx-xxxx-xxxx-781ee556ab7a", "modified_at": "2024-05-01T16:13:03.773+00:00" } } ``` ## Next steps * [Workflow versioning and drafts](/docs/workflow-builder-api/workflow-builder101/versioning) * [Steps](/docs/workflow-builder-api/workflow-builder101/steps) * [Branching rules](/docs/workflow-builder-api/workflow-builder101/branching-rules) * [Monitor a workflow](/docs/workflow-builder-api/workflow-builder101/monitor-workflow) * [Workflow start methods](https://support.docusign.com/s/document-item?language=en_US\&bundleId=yff1696971835267\&topicId=ztb1727892686033.html)