Automations - System-Wide Concepts

  • Updated

This article explains the foundational ideas that apply across all Automations in Process Studio. Understanding these concepts ensures that automation designers, admins, and viewers share a common vocabulary and know how core components behave across the entire system.

Core Concepts

  • Automation

An Automation is a named process built inside Process Studio. It defines a sequence of steps that run automatically when a defined event occurs. Every automation must start with a Starting Rule, followed by one or more steps that perform actions, apply logic, or move data forward.

  • Starting Rule

A Starting Rule is the event that starts, or triggers, an automation. It determines when and why the automation runs. Automations supports two starting rule types:

  • Timer Starting Rule – Runs the automation on a schedule (hourly, daily, weekly).
  • Event Starting Rule – Runs the automation when an external or internal event occurs (e.g., new report, webhook event, status change).

Note: Without a Starting Rule, an automation cannot run.

  • Step

A Step is a unit of work inside the automation. Each step performs one of the following:

  • Action (send data, call a connector, update a record).
  • Condition (If/Else decision).
  • Variable manipulation (store or update data).
  • Loop (repeat logic over a list of items).

Steps connect in sequence, forming a clear flow of logic from start to finish.

  • Execution

An Execution is a single run of an automation from beginning to end. Every time a starting rule fires, an execution begins and is logged under the Executions tab.

Executions include:

  • Overall status (Success or Failure).
  • Start and end timestamps.
  • Duration.
  • Raw JSON input and output for each step.
  • Error details (if failures occur).

This history allows teams to troubleshoot and analyze workflow behavior over time.

  • Version vs. Checkpoint

Automations provides two ways to manage changes:

1. Version

  • A published, stable milestone of automation.
  • Only published versions can run in production.
  • You can roll back to any published version.
  • Automatically created when publishing a new version. 

2. Checkpoint

  • A manually saved draft created while editing the automation.
  • Checkpoints are not runnable.
  • They act as safety points during editing but do not replace Version control.

     

  • Data Flow & Lifecycle

Automations follow a consistent lifecycle from creation to execution:

  1. Draft – The designer creates the automation and begins building steps.
  2. Save as Checkpoint – Changes are stored as a checkpoint.
  3. Publish – A stable version becomes active and ready to run.
  4. Execution – The automation runs each time its starting rule fires.
  5. Execution Records – Each run is logged for visibility and troubleshooting.
  6. Version Rollback – Admins can restore a previous version as needed.