Hi Asana Community!
Back in January we launched Scheduled Triggers V1, and many of you asked the same follow-up: “this is great, but when can it act on tasks that already exist in my project?” Today is that day. ![]()
What’s new
Most rules in Asana react to something happening to a task (a custom field changes, a due date approaches), and that same task is what the rule then acts on. Scheduled triggers are different: they fire based on time, so there’s no task kicking things off and no obvious task to act on. In V1, a scheduled trigger could only do things that didn’t need an existing task to act on — like creating a new task or drafting a status update with AI.
V2 changes that. Scheduled rules can now run on a defined set of tasks already in your project. That means you can automate the kind of recurring project maintenance and coordination work that used to require manual cleanup every Monday morning – reassigning work, updating fields, moving tasks between sections, archiving stale items, and more.
What is a “scope”?
When you pick a scheduled trigger, you’ll now see a new step called execution scope. This is where you tell the rule which tasks to act on when it runs.
You can choose from things like:
- All tasks in the project
- Just incomplete tasks
- Tasks in a specific section
- Tasks matching a custom field value
- Tasks last modified more than X days ago
- …and more
A quick note on why this is a scope and not a condition, since a few of you have already asked: conditions in Asana are always checked against the single task that sets the rule off. With scheduled triggers, no task sets the rule off – time does. So instead of asking “does this one task meet these conditions?”, we needed a way to ask “which tasks in this project should I go find and run this on?” That’s the execution scope.
Workflows this unlocks
A few of the ones we’re most excited about, several of which came directly from your requests:
- Stale task cleanup. Every morning at 9am, find tasks where Last Modified is more than 7 days ago and assign them to a project lead for review — or auto-comment “please provide an update.” This is the trigger many of you have been asking for, finally possible.
- Monday morning triage. Every Monday at 8am, take everything in your “This Week” section and reassign it, re-prioritize it, or move it forward.
- Recurring resets. Every Sunday night, reset the Status field on a recurring task back to “Needs agenda,” or clear out an Actual Time field across a set of tasks.
- Escalation on aging work. Every day, find tasks where Priority = High and Status = Not Started, and reassign them to a supervisor.
- Weekly reminders to a group. Every Friday, send a custom notification to the assignee of every task still open in a workflow stage.
A small nod to the future
Execution scope is the first step toward a bigger shift in how Rules work. Today, a rule acts on the one task that set it off. In the future, we want every part of a rule – the trigger, any conditions, and each action – to be able to have its own scope. That’s how we’ll get to workflows like “when something changes in Project A, go update a specific task in Project B” – what kicks the rule off and what the rule acts on don’t have to be the same task anymore.
V2 of Scheduled Triggers is the first place this idea shows up in the product, but it won’t be the last.
As always, let us know what you build with this and what you want next. ![]()
