WORKFLOWS / CONNECTED DATA AND ACTIONS

Automate the work around your data.

Use record triggers, conditions, and ordered steps to turn a business rule into application behavior. Start with a rule you can test and explain.

Start building

See the product

A SMALL RULE WITH A VISIBLE RESULT

An order arrives without a status. Save it as a draft.

A before_create workflow can update the record context before it is stored. This example keeps the existing orders status values.

Trigger: an order is being created.

The before_create trigger receives the incoming order record.

Condition: status is empty.

The workflow checks record.status with the supported is_empty condition. Orders with an explicit status do not take this path.

Action: set the record status.

A set_record step writes draft into the current record context before persistence.

INCOMING RECORD

{
  "orderNumber": "A-1042",
  "total": 184.5
}

RECORD CONTEXT AFTER THE RULE

{
  "orderNumber": "A-1042",
  "total": 184.5,
  "status": "draft"
}

Worked configuration example. Define the orders fields and allowed status values in your own project, then test the workflow with an authorized request.

THE RULE AS CONFIGURATION

A workflow you can read.

The trigger, condition, and action are explicit in the definition. Use the workflow editor to configure and inspect the behavior in your project.

Use this supported definition as a starting point, then inspect its execution with a test order in your project.

Follow the complete workflow tutorial ↗

{
  "name": "default-draft-status",
  "trigger": "before_create",
  "mode": "transactional",
  "isActive": true,
  "stopOnError": true,
  "conditions": [
    {
      "field": "record.status",
      "operator": "is_empty"
    }
  ],
  "steps": [
    {
      "name": "set-draft",
      "type": "set_record",
      "order": 10,
      "isActive": true,
      "config": {
        "values": {
          "status": "draft"
        }
      }
    }
  ]
}

MATCH THE MODE TO THE WORK

Keep the execution boundary deliberate.

Data mutations and external side effects have different failure and retry needs.

Transactional work stays with the record operation.

Use supported transactional steps for the data changes that must follow the request boundary.

Outbox work handles configured side effects.

Use outbox execution for supported follow-up operations that need durable delivery and configured retry behavior.

Hybrid workflows combine the two.

Keep the immediate data work and the deferred side effects in their intended execution modes. Verify the resulting execution and error behavior with your own records.

Execution-mode guide

Retries and idempotency

YOUR NEXT STEP