Asana Rules can give an incoming request a clear owner and destination. Start with one routing decision that your team already understands. A useful automation should make the next review easier, while leaving incomplete or unusual requests visible for a person to assess.
Asana announced the name Automations and a redesigned builder in September 2026. Existing rules continue running, while availability varies during rollout. Your account may show Automations where older help pages say Rules. Use the setup logic below and check the labels and available targets in your account.
Table of Contents
Check the plan and project first
The custom rule builder is available on Starter, Advanced, Enterprise and Enterprise+, plus legacy Business and Legacy Enterprise. Legacy Premium has a limited preset selection. Asana lists a maximum of 50 rules per project, with up to 20 triggers and 20 actions per custom rule.
Define one routing decision
For an illustrative agency workflow, create a request project with New requests and Website triage sections. Use a Request type field with a Website update option. A matching request should reach the coordinator responsible for checking scope; assignment does not mean the agency has accepted a delivery deadline.
Our Asana Forms guide covers collecting requests, while the custom fields guide explains consistent field setup. Agree the options and the coordinator before building this rule.
Build the trigger, condition and actions
Open the project’s automation builder; older layouts use Customize and Rules. In the trigger card, choose the event for a task being added to this project. Asana’s trigger guide explains that a trigger is an event: it is different from a task merely sitting in a matching state.
Add a condition requiring Request type to equal Website update. Asana’s conditions guide separates the event from the check that permits an action. If you later need two checks, use the option requiring both; choosing either instead can admit requests you intended to exclude.
In the action card, configure assignment to the coordinator and movement to Website triage. These are supported rule actions. Give the rule a descriptive name, such as “Route website requests for review”, and publish it only after the target check below. Publishing activates the rule.
Check the action target before publishing. In the new builder, Project contents can affect every task in a project unless narrowed with filters. This example should change only the intended request. Check the selected scope and matching tasks; if you cannot isolate the intended target, leave the automation paused and triage manually. Asana’s scope instructions also state that an automation matching more than 150 tasks will not run.
Keep the first version to those two actions. Automatically creating subtasks or setting a delivery date would add decisions this example has not yet justified. The coordinator can inspect the brief and agree the next step before anyone treats the request as committed work.
Decide what happens to exceptions
A request with a blank or different type should stay available for manual triage under this design. If you add branching later, Asana checks branches from top to bottom; place specific cases above broad ones. An Otherwise branch handles cases that meet none of the other branches. Give that fallback an explicit review owner rather than treating every unmatched request as ready for production.
If staff classify requests after arrival, consider a field-change trigger instead of relying only on addition to the project. Asana documents a trigger that monitors changes to the selected custom field. That is a different event, so rehearse the actual order in which your team creates and classifies work. Check that later corrections will not unexpectedly reassign an already accepted task.
Give the rule a responsible owner
People with permission to edit project workflows can edit, enable or disable its rules and claim ownership. Guests can trigger rules but cannot create or own them. Asana’s permissions guidance also distinguishes rules with external app components: adding or replacing those components requires the rule owner. Name a backup colleague who has the necessary workflow access.
The current automation scope guidance says an automation runs with its owner’s permissions. Check the owner’s access to referenced projects, fields and filters, especially after a team change. An inaccessible item can prevent the intended change.
Rehearse and inspect the result
Try a harmless new request with the matching field already populated, then another with a different type. Under this design, only the matching request should receive the routing actions. Check the task’s owner and section directly.
Open the rule’s three-dot menu and choose Rule history. The execution history shows success or failure, execution time, affected task, actions and edits. Use it to distinguish a recorded failed run from a request whose intended trigger never occurred. Compare the exact request and time before changing the configuration.
Asana’s rules guidance says it emails the owner when a misconfigured rule first fails. Check the rule’s status as well as the inbox. In its settings, review whether other rules may trigger it and whether it applies to subtasks; leave those choices aligned with the workflow you rehearsed.
Handle existing tasks deliberately
For older requests, Asana supports manual triggers. Create a separate rule with a manual trigger, a clear label and the routing actions you want. Run it from the task menu after checking the request yourself. This avoids assuming that adding a new automation will process the backlog.
Project admins and editors can run manual rules; commenters and viewers cannot. Manual rules do not run on subtasks, and a batch can include up to 50 selected tasks. Start with one suitable request, inspect the result, then select any remaining tasks deliberately. Keep a short record of which backlog items still need a human decision.
Sources reviewed 7 October 2026. This guide is based on Asana’s documentation; the agency workflow is illustrative and has not been presented as a hands-on product test.
