Documentation/Product

Automations

Triggers, conditions, actions. None of the low-code pain: a clear model and an execution log.

Model

Every automation has three parts:

Trigger: What kicks it off: a project is created, a form is submitted, a task is overdue, a milestone closes.
Conditions: Optional filters: only for projects tagged X, only for Enterprise, etc.
Actions: What runs: create a task, send a webhook, reassign, update a field.

Ready-made recipes

The automation catalog has dozens of ready-made scenarios:

Escalate to a manager if a task is 3+ days overdue.
Auto-flip a milestone's status to At risk if less than 48 hours remain.
Remind the customer in the portal and by email if a task has been idle.
Create a “Review the form” task when a key form is submitted.
Post to Slack when a phase moves to Completed.

Conditions

Conditions are tree-shaped. You can build expressions like:

AND
  project.tag != "internal"
  project.health == "red"
  OR
    task.assignee == @currentUser
    task.priority == "p0"

Tip

Before publishing an automation, run it as a dry run: it replays against existing data with no side effects and shows you what would have fired.

Execution log

Every run is written to the log with a deterministic ID, a timestamp, its input, its result, and any errors. The log is kept for 90 days (1 year on Enterprise).

Limits

Up to 1,000 actions per minute per tenant.
A maximum of 50 steps per automation.
Webhooks retry up to 5 times with exponential backoff.