Workflows are templates with versioned updates that keep a related set of records in sync between multiple environments (e.g. dev, staging, production).

Here’s a simple workflow KATA template that creates a new task using a configurable name and owner.

workflow:
  name: example.newTask
  version@date: 2025-12-31T00:00:00Z
  description: This example workflow manages a task record
  requirements:
    cerb_version: >=10.5 <11.0
    cerb_plugins: cerberusweb.core,
  config:
    text/taskName:
      label: Task name:
      default: New task from a workflow
    chooser/taskOwner:
      label: Task owner:
      multiple@bool: no
      record_type: worker
      record_query: isDisabled:n

records:
  task/newTask:
    deletionPolicy: retain
    fields:
      owner_id: $${config.taskOwner_id|default(0)}
      title: $${config.taskName}

When you make a changes to a workflow template, any records that were previously created by the workflow are automatically updated to match. The workflow manages the mapping between template “keys” and local record IDs.

• Workflow KATA
  • Schema
    • config:
    • extensions:
    • records:
  • Placeholders

Workflow KATA

Schema

config:
  chooser:
    default:
    label:
    multiple@bool:
    record_query:
    record_type:
  text:
    default:
    label:
extensions:
  activity:
    id:
    label:
    message:
  permission:
    id:
    label:
  translation:
    id:
    langs:
      {lang_code}:
records:
  {type}:
    deletionPolicy:
    fields:
    updatePolicy:

config:

extensions:

records:

Each record is defined with a record type and unique key.

For example: task/newTask:

Placeholders

To avoid conflicts with the usual {{placeholder}} syntax found in records like automations and snippets, Workflow KATA provides two special scripting functions: cerb_workflow_config() and cerb_workflow_resources().

From any feature that supports automation scripting (e.g. automations, workflows, snippets) you can use {{cerb_workflow_config('workflow_name')}} to dynamically read workflow configuration values at runtime. For instance, you can create a workflow just for sharing values (e.g. API keys) between multiple workflows.

Read a single key with a default value using: {{cerb_workflow_config('workflow_name','hashSecret','default')}}

The {{cerb_workflow_resources('workflow_name')}} function performs runtime lookups and returns a map of workflow resources and their local record IDs. This is useful from automations, event listeners, and toolbars.

Statically replace configuration values in the template with: $${config.keyName}

If the configuration value is a chooser:, you can expand its dictionary keys like: $${config.keyName__label}

Workflow placeholders also support automation scripting filters, such as: $${config.keyName|lower|sha1}