Build a workflow
Workflows are multi-step automations: an event fires, optional conditions filter it, and a chain of steps runs (update a task, notify someone, wait, ask for approval, call an external system). You build and manage them from Workflows in the sidebar.

Triggers
Section titled “Triggers”Every workflow starts from one trigger event. The builder groups them into five families:
- Tasks: task created, status changed, priority changed, assignee changed, progress changed, task completed, due date passed, due date approaching, attachment added, tag added, tag removed.
- Projects: project created, project status changed, milestone reached, budget exceeded, budget threshold reached, project billability changed.
- Activity: comment added, time logged, timesheet submitted, approved, or rejected.
- Governance: proposal created, stage changed, approved, or rejected, gate review requested or submitted, change request created or status changed, intake form submitted.
- Organization: member joined, member removed.
Each trigger can carry a condition (for example, only fire Task status changed when the new status is Done). You can also add a recurring Schedule (cron expression plus timezone) under the builder’s advanced options; a schedule fires independently of the trigger event.
After the trigger, you chain steps of five kinds:
- Action: the workhorse. Actions are grouped into Update task (set
status, priority, progress, assignee, due date, custom fields, and more),
Organize (add or remove tags, move to sprint, epic, or another project,
create a subtask), Communicate (post a comment, send an in-app
notification, send an email with placeholders like
{task.title}), Project & milestones, Governance, Integrations (call a webhook), and AI agent. - Condition: branch on a field check (Task Status, Priority, Progress, Assignee, Project Status, or Project Type) with true and false paths.
- Delay: wait a number of minutes, hours, or days before the next step.
- Approval: pause until designated people sign off. See Add approval steps to a workflow.
- Webhook: POST a payload to an external URL.
Create a workflow
Section titled “Create a workflow”-
Open Workflows and select New Workflow.
-
Name it, then pick the scope. Org-wide workflows run against every project; project-scoped workflows run only in the project you pick.
-
Choose the trigger event and any trigger conditions.
-
Add steps and connect them. Condition and approval steps let you wire separate branches for each outcome.
-
Save. Once saved, Test Run fires the workflow once against the latest matching item so you can verify it before real events hit it.
Watch it run
Section titled “Watch it run”The Activity tab on the Workflows page is the run history: every run with its status (running, waiting on a delay or approval, succeeded, failed), a full step-by-step timeline, and options to cancel a stuck run or retry a failed one.
Who can build workflows? Owners, Admins, and Portfolio Managers manage org-wide workflows. For a project-scoped workflow, the project’s automation permission applies, so a project owner or manager can automate their own project.
What is the difference from per-project automations? Workflows are the org-level surface with branching, delays, and approvals. The same engine powers them; use Workflows when a rule should span projects or needs more than a single trigger-action pair.
Do workflows run retroactively? No. A workflow only reacts to events that happen after it is saved and active. Use Test Run to exercise it against existing data once.
Was this helpful?
Thanks for your feedback!