Workflows

Track records through the steps of a business process — with checklists, rotting alerts, and current-step tracking.

Overview

Workflows track a record’s progress through the steps of a business process — a sales pipeline, an onboarding flow, a fulfillment process. A workflow defines an ordered set of steps; each record on the workflow tracks its current step and moves through them over time. Steps can carry checklist items and rotting alerts. For the mental model, see Core concepts.

A workflow is bound to one object type (for example Contacts or Orders), and a record can be on several workflows at once.

Workflows is a shared feature. The per-module pages — Content Workflows, Commerce Workflows, Customer Data Workflows — are the same feature surfaced in each module; this is the canonical reference.

Where to find it

Workflows are configured in Utilities.

Properties

A workflow definition has the following properties:

Property	Type	Required	Description
title	string	Yes	Display name of the workflow.
slug	string	Yes	Unique identifier — letters, numbers, and hyphens only.
object_type	enum	Yes	The object type this workflow applies to. Can’t be changed after creation.
description	string	No	Optional description.
workflow_steps	array	Yes	The ordered list of steps.
created_at	datetime	Auto	When the workflow was created.
updated_at	datetime	Auto	When the workflow was last updated.

Steps

A workflow’s steps are its stages, in order. Each step has:

Property	Type	Required	Description
title	string	Yes	Step name (use clear, action-oriented names like Lead, Qualified, Closed Won).
slug	string	Yes	Step identifier.
rotting_days	number	No	Days before a record stuck at this step is flagged stale — see Rotting alerts. 0 disables it.
items	array	No	Checklist items for the step.

Checklist items

A step can carry checklist items — completion requirements for that stage. Each item has a title; whether it’s been completed (checked) is tracked per record as it moves through the workflow. A common pattern is to require all items checked before a record can advance to the next step.

Rotting alerts

Each step can set rotting_days — once a record has sat at that step for that many days, it’s flagged as rotting (stale) so it can be surfaced and acted on. Set 0 to disable the alert for a step.

Progress

Each record stores which workflow(s) it’s on and its current step in each. Records advance step by step over time, and because a record can hold multiple workflows, the same object can move through several processes in parallel (for example a sales pipeline and an onboarding flow).

Behaviour & rules

• object_type is fixed. A workflow’s object type is set at creation and can’t be changed afterward.
• slug is required and unique, using only letters, numbers, and hyphens.
• Steps match the workflow. A step belongs to its workflow’s object type.
• Multiple per record. A record can be on several workflows at the same time.

Seeds

Workflow definitions travel between environments as structural Seeds only — instance seeds don’t apply. Each is a workflows item with its steps embedded under workflow_steps:

[
  {
    "object_type": "workflows",
    "data": {
      "title": "Content approval",
      "slug": "content-approval",
      "object_type": "content_instances",
      "workflow_steps": [
        { "title": "Proposed", "slug": "proposed", "rotting_days": 0, "items": [] },
        { "title": "In review", "slug": "in-review", "rotting_days": 0, "items": [{ "title": "Approve" }] },
        { "title": "Approved", "slug": "approved", "rotting_days": 0, "items": [] }
      ]
    }
  }
]

Governance & permissions

Only a super admin or Master can create, edit, and delete workflows.

API access

Workflow definitions (and their steps) are managed through the API. A record’s progress is set through its workflows — the workflow it’s on and its current step. See the API reference.

Related

Object types

Which object types support Workflows.

Views

Surface records by their workflow and current step.