Sign in

v2

latestOpenAPI 3.0.02026-07-31226285.0 KB
Flows V2

createFlowTemplate

Create a new Flow Template (V2 workflow definition).

A flow template defines the structure of a workflow including its phases, tasks, edges (connections between tasks), and trigger configuration. Once created, the template can be used to start workflow executions.

post/v2/flows/templates

Query parameters

enforce_limitsboolean

When true, size/count limit violations (max incoming edges per task, max branches, max entity-sync rules, ...) are enforced as 400 errors. Used by the flow-builder UI for interactive authoring. On update, pre-existing violations are tolerated as long as the request does not worsen them. When false or absent (default for API/system callers such as blueprints, configuration hub and snapshots), limit violations are accepted and returned as limit_warnings. Structural errors are always enforced regardless of this flag.

Request body

idstring

Unique identifier for the flow template, generated by the system.

org_idstring

Organization identifier that owns this flow template.

namestring required

Display name for the workflow, shown to users in the UI.

descriptionstring

Optional detailed description of the workflow's purpose and behavior.

enabledboolean

Whether the workflow is enabled or not

version'v1' | 'v2' | 'v3'

Version of the workflow schema.

  • v1 – Deprecated. The initial version of workflows with limited structure and automation capabilities.
  • v2 – Linear workflows. Supports sequential task execution with basic automation triggers.
  • v3 – Advanced workflows. Adds support for branching logic (conditions), parallel paths, and enhanced automation features such as dynamic triggers and flow control.
created_atstring

ISO String Date & Time

updated_atstring

ISO String Date & Time

due_datestring
available_in_ecpboolean

Indicates whether this workflow is available for End Customer Portal or not. By default it's not.

taxonomiesstring[]

Taxonomy ids that are associated with this workflow and used for filtering

singleClosingReasonSelectionboolean

Whether only a single closing reason can be selected

_manifeststring[]

The manifest IDs associated with this workflow

linearboolean

When true, this is a linear flow: task enablement is computed at runtime from the graph — a task is enabled only when all of its direct predecessor tasks in its branch are done. This fully overrides any explicit per-task requirements.

keep_task_automations_in_syncboolean

Persisted preference for how the flow's task automations relate to the flow's enabled state. When true, task automations always mirror the flow: their enabled state is re-synced on every update and new task automations are created with the flow's current enabled state. When false, task automations are managed independently: updates never change their enabled state and new task automations are always created enabled, so a flow that is built or edited while disabled does not accumulate automations that stay off after the flow is re-enabled. When unset, legacy behavior applies: new task automations inherit the flow's enabled state and updates leave existing ones untouched. Safety: on updates that do NOT change enabled, the in-sync mode never re-enables automations that were disabled by the system (e.g. infinite-loop protection) — only a deliberate enabled flip on the flow re-arms those.

Example request

{
  "created_at": "2021-04-27T12:01:13.000Z",
  "updated_at": "2021-04-27T12:01:13.000Z",
  "due_date": "2021-04-27T12:00:00.000Z",
  "assigned_to": [
    {
      "variable": "{{entity.owner}}",
      "value": [
        "user_12345"
      ]
    }
  ],
  "phases": [
    {
      "due_date": "2021-04-27T12:00:00.000Z",
      "assigned_to": [
        {
          "variable": "{{entity.owner}}",
          "value": [
            "user_12345"
          ]
        }
      ]
    }
  ],
  "tasks": [
    {
      "due_date": "2021-04-27T12:00:00.000Z",
      "assigned_to": [
        {
          "variable": "{{entity.owner}}",
          "value": [
            "user_12345"
          ]
        }
      ]
    }
  ],
  "entity_sync": [
    {
      "trigger": {
        "event": "FlowStarted"
      },
      "target": {
        "entitySchema": "opportunity",
        "entityAttribute": "title"
      },
      "value": {
        "source": "workflow_name"
      }
    }
  ]
}

Response

Success - if the flow template is created successfully

idstring

Unique identifier for the flow template, generated by the system.

org_idstring

Organization identifier that owns this flow template.

namestring required

Display name for the workflow, shown to users in the UI.

descriptionstring

Optional detailed description of the workflow's purpose and behavior.

enabledboolean

Whether the workflow is enabled or not

version'v1' | 'v2' | 'v3'

Version of the workflow schema.

  • v1 – Deprecated. The initial version of workflows with limited structure and automation capabilities.
  • v2 – Linear workflows. Supports sequential task execution with basic automation triggers.
  • v3 – Advanced workflows. Adds support for branching logic (conditions), parallel paths, and enhanced automation features such as dynamic triggers and flow control.
created_atstring

ISO String Date & Time

updated_atstring

ISO String Date & Time

due_datestring
available_in_ecpboolean

Indicates whether this workflow is available for End Customer Portal or not. By default it's not.

taxonomiesstring[]

Taxonomy ids that are associated with this workflow and used for filtering

singleClosingReasonSelectionboolean

Whether only a single closing reason can be selected

_manifeststring[]

The manifest IDs associated with this workflow

linearboolean

When true, this is a linear flow: task enablement is computed at runtime from the graph — a task is enabled only when all of its direct predecessor tasks in its branch are done. This fully overrides any explicit per-task requirements.

keep_task_automations_in_syncboolean

Persisted preference for how the flow's task automations relate to the flow's enabled state. When true, task automations always mirror the flow: their enabled state is re-synced on every update and new task automations are created with the flow's current enabled state. When false, task automations are managed independently: updates never change their enabled state and new task automations are always created enabled, so a flow that is built or edited while disabled does not accumulate automations that stay off after the flow is re-enabled. When unset, legacy behavior applies: new task automations inherit the flow's enabled state and updates leave existing ones untouched. Safety: on updates that do NOT change enabled, the in-sync mode never re-enables automations that were disabled by the system (e.g. infinite-loop protection) — only a deliberate enabled flip on the flow re-arms those.

Example response

{
  "created_at": "2021-04-27T12:01:13.000Z",
  "updated_at": "2021-04-27T12:01:13.000Z",
  "due_date": "2021-04-27T12:00:00.000Z",
  "assigned_to": [
    {
      "variable": "{{entity.owner}}",
      "value": [
        "user_12345"
      ]
    }
  ],
  "phases": [
    {
      "due_date": "2021-04-27T12:00:00.000Z",
      "assigned_to": [
        {
          "variable": "{{entity.owner}}",
          "value": [
            "user_12345"
          ]
        }
      ]
    }
  ],
  "tasks": [
    {
      "due_date": "2021-04-27T12:00:00.000Z",
      "assigned_to": [
        {
          "variable": "{{entity.owner}}",
          "value": [
            "user_12345"
          ]
        }
      ]
    }
  ],
  "entity_sync": [
    {
      "trigger": {
        "event": "FlowStarted"
      },
      "target": {
        "entitySchema": "opportunity",
        "entityAttribute": "title"
      },
      "value": {
        "source": "workflow_name"
      }
    }
  ]
}