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 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, scenario applied to portfolio, readiness check recorded, closeout signed off, project archived, project unarchived.
- Lists: row added to a List, including a submission from a published app form.
- Documents: document uploaded, new document version. These two are part of document approval, on Business and above.
- 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 with Also run on a schedule under the builder’s More options: every day, every weekday, every Monday or the first of every month at 9:00, or a Custom schedule (cron), in the Time zone you pick. 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 with true and false paths. The fields on offer depend on the trigger: the ones its event carries (Task Status, Priority, Progress or Assignee on task events, Hours submitted for the week on Timesheet submitted, Overdue on Due date passed, and so on), plus Project Status and Project Type wherever the event names a project. See How conditions are checked.
- 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”New Workflow opens a start screen, What should Onplana do for you?, with three ways in:
- Build it step by step (marked Recommended): select Start for the blank builder, then answer when it should run and what it should do. The steps below follow this path.
- Describe it in your own words: type what you want, for example When a task is overdue, wait a day, then email me, and select Fill in the form. The AI proposes when it runs, a name and the steps, and fills them into the same builder for you to check. If it cannot tell when the steps should run, it asks When should it run? first; pick the trigger and select Use these steps. See Draft a workflow with AI.
- Use a ready-made one: Browse templates opens the template gallery. Templates start paused so you can check them.
Below them, Popular ideas, one click to start opens a few shipped templates your plan can use directly.

The builder reads as a sentence: a Name, a WHEN block that says when the workflow runs, the steps under it, and a side panel that sums the whole workflow up In plain words as you build. On a narrow screen the side panel moves below the steps. Every workflow, new or saved, opens in this layout.
-
Open Workflows, select New Workflow, and on the start screen select Start under Build it step by step.
-
Give it a Name.
-
In the WHEN block, select Change to pick the trigger from the grouped, searchable list. For a status or priority change, the sentence carries its own From and To choices, for example A task in Website moves from any status to Done; other filters a trigger can take show under the sentence.
-
Add what it does with the add row under the last block: Do something, Only if… (a check with If yes and If no lanes), Ask someone to approve (with If approved and If rejected lanes), Wait first, or Then do something else. Each block reads as a sentence, such as Email the task’s assignee or Wait 2 days, then go on, and its menu collapses, moves, duplicates or removes it.
-
Under More options in the side panel, choose what it Watches: All projects (org-wide) or One project, with the project to watch. The scope is fixed once the workflow is saved.
-
Save with Save and turn on or Save, keep paused. On a saved workflow that is on, the buttons read Save and Save and pause. The On / Paused switch in the side panel shows which it will be. Once saved, Test Run fires the workflow once against the latest matching item so you can verify it before real events hit it.
To change a saved workflow in words instead of by hand, select Ask AI to change this at the top of the builder (on a new one it reads Describe it with AI). The AI redrafts the steps for the workflow’s trigger, nothing is saved until you save, and the workflow keeps whether it was on or paused.
Automate from an item’s menu
Section titled “Automate from an item’s menu”You do not have to start from the Workflows page. The ⋯ menu of a project, a task, a folder, a document and a List has Automate in its Do more block. It opens the builder with the scope set to the item’s project and the trigger already chosen:
| On | Automate offers |
|---|---|
| A project | When the project’s status changes, when a milestone is reached, or when spending reaches a share of the budget |
| A task | When a task changes status, when a task is created, or when a task becomes overdue (all in the task’s project) |
| A folder | When a file is uploaded here, or when a document here gets a new version |
| A document | New document version, filtered to that document |
| A List | Row added to a List, targeting that List |
Where there is more than one trigger, Automate opens a list beside the menu and you pick one. The folder and document triggers carry a filter for that folder or document, which shows under the WHEN sentence and you can remove. A task trigger runs for every task in the project, since a task event cannot be narrowed to one task.
The builder opens straight on that item, with no start screen and no template gallery, and suggests a name from your choice, such as When a task in Website moves to Done or When a row is added to Leads. The name follows your choices until you type your own. To start from a template instead, select the link that reads, for example, See 4 ready-made workflows for tasks: the gallery opens on that kind of item, with up to three templates that fit the trigger under Fits this trigger. A template you apply keeps the folder, document or List filter, so a sign-off template opened from a folder listens to that folder only.
Once an item has workflows, its menu reads Automations with the count. It lists each workflow with whether it is active or paused, how many times it ran and when it last ran, and a New automation button. On a project, a task or a folder the count comes first in the list beside the menu, above the triggers.
Automate is on Pro and above, and the folder and document triggers need Business. On a plan without automations the item shows a lock with the plan named, and choosing it opens the upgrade offer, including the Pro trial where one is available. Guests do not see the item. See also Do more from any item.
How conditions are checked
Section titled “How conditions are checked”Trigger conditions and condition steps compare the same way, and a few rules decide what they see. These changed in October 2026; if a workflow behaves differently since then, the reason is likely here.
- A trigger condition the engine cannot read never fires. A condition with a key it does not know, a value with no operator, or an operator outside its set used to be skipped, so the workflow fired on every event of its kind. It now fires on none, and saving such a condition through the API is refused with the reason. The builder only saves conditions the engine can read.
- A trigger condition on a field its event does not carry does not match. For example, a Task status changed trigger filtered on priority never fires, because that event carries only the status.
- Empty is one value for equals and not equals. A blank value, a cleared field and Unassigned (no assignee) all count as the same empty value. So “Assignee equals Unassigned” now matches a task with nobody on it, and “Assignee does not equal empty” no longer passes for one. Greater than, less than and contains work as before.
- Due date passed carries the task’s real status. The event used to send
the status
OVERDUE, which is not a task status. It now sends the task’s actual status (To Do, In Progress and so on) and a separate Overdue field set to true. A condition or trigger testing status equalsOVERDUEnow matches nothing: test Overdue equals true instead. - Timesheet submitted carries the week’s total hours. Hours submitted for the week is the person’s submitted and approved hours for that week in your workspace, so a week sent in two parts is judged on all of it.
- A condition step reads what the event carried. A task event carries only what changed, so a step on another task field (a priority check after a status change, say) has no value to compare: “equals” is false and “does not equal” is true. Reading the field from the task itself as the step runs is built, but it is a server setting that is off by default. Until it is on, a step after a Delay or Approval also compares the value the event carried when the run started, not the task’s value now.
Shipped templates
Section titled “Shipped templates”Four templates were corrected along with these rules.
| Template | What to expect |
|---|---|
| Auto-Assign New Tasks | Assigns an unassigned new task to its creator and sets it In Progress once condition steps read from the task. Until then the new task event does not carry the assignee, so every run ends without assigning. |
| SLA Breach Alert | Checks four hours after a task is created. Once condition steps read from the task, it emails the creator and assigns the task to them only if it is still in To Do. Until then it compares the status the task was created with, so every task created in To Do gets the email and the reassignment. |
| Auto-Process Timesheets | Newly added copies test Hours submitted for the week: a week over 40 hours sends the manual review notification. An older copy still tests progress, which this event never carries, so every week goes to manual review until you change the step’s field to Hours submitted for the week. On the 40-hours-or-less path, Auto-approve timesheet approves the submitted week as the workflow’s creator, who must be a timesheet approver for that person; it never approves the creator’s own week, and when a rule is not met the run fails with the reason and the week waits for a person. See Approve weeks with a workflow. |
| Overdue Task Follow-Up | Newly added copies notify the assignee, wait two days, and then check Still open? before raising the priority to Critical. That check skips a task finished during the wait once condition steps read from the task; until then it escalates every task, as before. An older copy has no Still open? step and keeps escalating every overdue task. To get the check, add the template again, or add a condition step on Status does not equal Done before the escalation; either takes effect once condition steps read from the task. |
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.
When a workflow changes a task, the task’s own History tab shows the change too, marked via workflow and the workflow’s name. See See which workflow changed a task.
Best practices
Section titled “Best practices”- Start with templates, customize later. The template gallery covers common patterns (proposal reminders, escalation, intake routing). Pick the closest one, adapt it. Faster than building from scratch.
- Use Test Run before activating. The dry-run feature exercises the workflow against real data without consequence. Verify each step fires correctly before flipping live.
- Name workflows clearly. “Escalate overdue task” beats “WF-001”. Names appear in run history and audit logs.
- Watch the Activity tab regularly. Failed runs need investigation; stuck-on- approval runs need a nudge. Don’t let failures accumulate.
- Recipe examples to copy:
- Auto-create-on-merge: GitHub webhook → create task with PR title + URL
- Escalate-on-overdue: Task due date passed + status not Done → 3-day delay → email manager
- Status-change notification: Task status → Done → post comment to project Slack channel via webhook
Troubleshooting / common pitfalls
Section titled “Troubleshooting / common pitfalls”- Workflow doesn’t fire on a matching event. Four causes: (a) trigger condition mismatches; (b) the condition tests a field the event does not carry, or one the engine cannot read (see How conditions are checked); (c) workflow paused; (d) its Stop after this many runs limit reached. Check Activity tab.
- A condition on status
OVERDUEstopped matching. Due date passed now carries the task’s real status. Test Overdue equals true instead. - Step failed mid-run. Failed runs show step + error in Activity. Retry once cause is fixed.
- Approval step stuck. Designated approver hasn’t acted. See Add approval steps to a workflow.
- Webhook returned non-2xx. External endpoint failed. Retry from Activity; fix the endpoint.
- Delay step taking longer than expected. Delays are coarse (minute granularity). A “wait 5 minutes” delay may fire at 4:59 or 5:01.
How this combines with other features
Section titled “How this combines with other features”- Workflows + Approvals. Multi-step approvals with delegation. See Add approval steps to a workflow.
- Workflows + Webhooks. Integration glue for external systems. See Send webhooks.
- Workflows + Intake forms. Auto- process inbound submissions. See Create public intake forms.
- Workflows + Email. Inbound email triggers + outbound notifications. See Receive email into projects.
Coming from another tool
Section titled “Coming from another tool”| Tool | Mapping |
|---|---|
| Zapier | Direct concept; Onplana workflows are first-party + free |
| Microsoft Power Automate | Direct concept |
| n8n | Direct; self-hosted alternative |
| ServiceNow Workflow Designer | Direct |
| Asana Rules | Direct |
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.
Can workflows call AI agents? Yes, the AI Agent action group lets a workflow delegate a step to a connected agent. See Assign work to an agent.
Are there workflow run limits? Workflows require Pro or above; the Free plan has no access to them. On Pro and up, there’s no per-plan cap on runs triggered by signed-in members, though you can set an optional Stop after this many runs limit on any one workflow. Only runs caused by anonymous public visitors (a public form submission, for example) carry a plan-scaled abuse budget.
Can a workflow trigger another workflow? Indirectly, via webhooks. There’s no direct workflow-to-workflow chain today.
Related
Section titled “Related”- Add approval steps to a workflow, multi-step approvals
- Send webhooks, external integrations
- Receive email into projects, inbound automation
Was this helpful?
Thanks for your feedback!