Sign in

v2

latestOpenAPI 3.0.02026-07-31226285.0 KB
Flows V2

duplicateFlowTemplate

Create a copy of an existing flow template. The duplicated template will have a new unique identifier and can be modified independently of the original. This is useful for creating variations of existing workflows without starting from scratch.

post/v2/flows/templates/{flowId}/duplicate

Path parameters

flowIdstring required

Short unique id (length 8) to identify the Flow Template.

Example:7hj28akg

Unique identifier of the flow template to duplicate.

Response

Flow template has been duplicated 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"
      }
    }
  ]
}