Skip to main content

Overview: Workflows

A workflow coordinates tasks to execute business logic. In Conductor, you can build workflows for process automation, event-driven processing, agentic orchestration, microservice orchestration, real-time API orchestration, and human approval flows.

A workflow defines how tasks run, in what order, and under which conditions. Conductor manages task execution, retries, state, and failure handling so you can focus on business logic instead of orchestration code.

Ways to create workflows​

In Conductor, all workflows are stored and executed as JSON workflow definitions. You can create a workflow using any of the following methods:

  1. Code: Using Conductor SDKs, define the workflow in any programming language (Python, Java, JavaScript, C#, Go, Clojure) and register it with the Conductor server. Once registered, Conductor generates and saves the JSON workflow definition. Learn more in Write Workflows as Code.
  2. API: Write the workflow in JSON and register it to the Conductor server using the /api/metadata/workflow endpoint.
  3. Conductor UI: Using the Conductor UI, you can design workflows in two ways:
    • Visual workflow builder: Define your workflow visually, which is formatted as JSON under the hood.
    • Assistant: Use a prompt-based interface to create workflows by describing them in natural language. The assistant generates the workflow definition for you.
  4. BPMN importer: Convert existing BPMN (Business Process Model and Notation) files into Conductor workflows using the built-in importer. This provides an easy migration path from BPMN-based systems.

Static vs dynamic workflows​

You can create workflows statically (ahead of time) or dynamically (at runtime). Dynamic workflows are created using the workflow-as-code approach, allowing you to write your workflow and task workers in your preferred language and execute them immediately. This is useful when you can't define workflows ahead of time because the number of tasks and flow control depend on real-time factors. Learn more in Write Workflows as Code.

AI-powered and agentic workflows​

Agentic workflows use AI-driven decision-making to determine which tasks to execute and when. Task execution can adapt dynamically with minimal human intervention while still allowing oversight when required.

Conductor’s AI orchestration capabilities let you build agentic workflows that are auditable, scalable, and safe to operate in production environments. Learn more in AI Orchestration and Agentic Workflows.

Human in the loop​

Human-in-the-loop workflows include tasks that require manual input, review, or approval. These workflows combine automated steps with human decision points, making them suitable for approval flows, exception handling, and review-based processes. Learn more in Human Task Orchestration.

Event-driven workflows​

Event-driven workflows start or progress based on external events. Conductor supports event-driven patterns through features such as webhooks, event handlers, and message broker integrations. Learn more in Eventing.

Gateway​

You can expose and trigger Conductor workflows through the Gateway, enabling workflows to act as real-time APIs or Model Context Protocol (MCP) tools. Learn more in Gateway.

Remote Services​

Remote services provide a centralized way to define and manage HTTP and gRPC endpoints that can be reused across workflows. Learn more in Remote Services.

Workflow definition​

A workflow definition contains configuration parameters that define the workflow behavior, including the flow of tasks, workflow inputs and outputs, schema, failure handling settings, and rate-limiting features. The most important parameter is the tasks array, which specifies the order and execution of the defined tasks and operators.

Here are the workflow configuration parameters:

ParameterDescriptionRequired/ Optional
nameWorkflow name.
  • For v4.0.1 and prior: Only letters, digits, hyphens (-), and underscores (_) are allowed.
  • For v4.0.2 and later: Only letters, digits, spaces, hyphens (-), underscores (_), and certain special characters (<, >, {, }, #) are allowed.
Note: It is recommended to use alphanumeric characters for workflow names. While special characters are allowed for backward compatibility, they are not fully supported and may cause unexpected behavior.		Required.
description​Workflow description.Required.
versionThe version number of the workflow. Increment the version when making breaking changes to the workflow definition. Learn more in Versioning Workflows.Optional.
schemaVersionThe current Conductor Schema version. Must be 2.Required.
tasksArray of task configuration objects. This defines the flow of tasks in the workflow.Required.
inputParametersArray of workflow input keys.Optional.
outputParametersJSON template used to generate the workflow output.

If unspecified, the workflow output will be the output of the last executed task.		Optional.
enforceSchemaWhether to enforce input schema validation. Set to true to enable validation.

Learn more about using schemas in Schema Validation.		Optional.
inputSchemaName and type of the input schema to be associated with the workflow.Required if enforceSchema is set to true.
outputSchemaName and type of the output schema to be associated with the workflow.Required if enforceSchema is set to true.
restartableWhether the workflow can be restarted after completion. The default value is true.

Set to false if restarting a completed workflow causes side effects.		Optional.
workflowStatusListenerEnabledWhether to enable status callback for workflow state changes. The default value is false.

Learn more in Enabling CDC.		Optional.
workflowStatusListenerSinkThe message broker sink where workflow state changes are sent.Required if workflowStatusListenerEnabled is set to true.
ownerEmailThe email address of the workflow creator.Required.
timeoutPolicyThe workflow timeout policy.

Learn more about workflow timeouts in Handling Failures.		Required.
timeoutSecondsThe timeout duration in seconds.

Learn more about workflow timeouts in Handling Failures.		Required.
failureWorkflowThe compensation workflow to trigger upon failure of the current workflow execution. Useful for cleanup, notifications, or post actions.

Learn more about compensation workflows in Handling Failures.		Optional.
rateLimitConfigA map of the workflow rate limit configuration.

Learn more about workflow rate limits in Workflow rate limits.		Optional.
rateLimitConfig. rateLimitKeyA unique identifier to group workflow executions for rate limiting.Optional.
rateLimitConfig. concurrentExecLimitThe number of workflow executions that can run concurrently for a given key.Optional.
maskedFieldsAn array of fields to be masked in the workflow execution.
Learn more about masking fields in Masking Parameters.		Optional.

Example​

Here is an example workflow definition JSON:

{
  "name": "exampleWorkflow",
  "description": "Example workflow definition.", 
  "version": 1,
  "tasks": [],
  "inputParameters": [
    "someKey",
    "anotherKey"
  ],
  "outputParameters": {
    "someOutput": "${task_reference_name.output.id}",
    "anotherOutput": "${workflow.version}"
  },
  "schemaVersion": 2,
  "restartable": true,
  "workflowStatusListenerEnabled": false,
  "ownerEmail": "user@example.com",
  "timeoutPolicy": "ALERT_ONLY",
  "timeoutSeconds": 0,
  "failureWorkflow": "",
  "maskedFields": []
}

Get started by choosing how you want to build workflows, using code, API, the Conductor UI, or by converting existing BPMN definitions.