I appreciate the new conditional logic that is provided by Asana for rules, namely “ALL” triggers happen, or “ANY” triggers happen. There is a lot of limitation to these “conditions”, and what would make these rules MUCH more flexible is if there was conditional logic based on the task’s CURRENT STATE.
Below I’m going to express different options available to select between parenthesis( )
For example, a setting where rules should (ONLY, or NOT) activate if:
- Task’s Custom Field (EQUALS, DOES NOT EQUAL, CONTAINS) “____________” (multiple options selectable for multi-select field-types)
- Task (IS IN, IS NOT IN) Section “_________”
- Task’s Due Date Field (IS, IS BEFORE, IS AFTER, IS BETWEEN) “__________”
- Task’s Assignee Field (IS, IS NOT)
- Task’s Completion Status (IS, IS NOT) “__________”
- Task’s Creation Date (IS, IS BEFORE, IS AFTER, IS BETWEEN) “_________”
- Task (IS, IS NOT) in Project(s) “________”
This would enable rules to be much more customizable to each user’s use case, and allow custom workflows that would stop rules from affecting ALL TASKS IN A PROJECT (huge limitation), and would only affect rules matching the conditional rules. It’s currently a huge limitation that rules only affect tasks that have had a STATE CHANGE. I know it would be possible resource-heavy to have rules activate based on a current state, but maybe that poll could be a fairly long poll (every 5 minutes) instead of instantly, per se to reduce server demand
+1 on this capability. Rules as they currently operate are effective, but I fully agree w/you that the ability to invoke a rule based on a task’s current state would put us over the hump. Perhaps it could be triggered “manually” by clicking a button. We could use this to automatically assign tasks to employees based on our Assignee Title custom field. The rule condition would be:
Where Assignee Title is Product Mgr, then assign John.Smith@ourcompany.com
Where Assignee Title is Portfolio Mgr, then assign Alice.Johnson@ourcompany.com
I wonder if this could be done w/Zapier or Flowsana.
I’m pretty sure this could be done with both, but much more easily with Flowsana (/cc @Phil_Seeman).
+1 from me as well. I found your post after trying to implement an automated urgency x impact = priority matrix. In this use case, I’m fine triggering on a state change, for example IF one field changes… BUT ONLY IF the other field (which has not changed) is whatever value.
This is by far the biggest thing I’m missing right now.
I have a rule for “When a comment is added, move to Inbox section”. But what I need is “When a comment is added by anyone other than me, move to Inbox”.
Or “When moved to the Snooze section, AND Due Date is not currently set, set the due date to +7d”.
Adding filters/conditions based on the pre-trigger state of the task would vastly improve my QoL & ability to automate my gigantic backlog.
Looks like similar suggestions a couple of years ago were closed, but being able to set a condition on a rule so that it only fires under certain circumstances would be great.
- Project A has a rule that when a task is created in the project it automatically assigns to User A
- Task is created in project B, assigned and being worked by User B.
- Task is recognized as having impact on project A and is multi-homed or moved entirely into Project A.
- Rule on Project A fires, and reassigns the task.
- Configure the rule to only run if there is no current assignee.
This is, of course, a single use case, but assigning based on a custom field, creating a subtask depending on a tag, moving to a section based on some other criteria… all these and more.
This feature would be so helpful. Many rules I would like to use require filters, like “only move this task to a new section based on due date IF it is not in X section already” or “move to a new section if someone other than me comments”
@Riley_Spicer (and everyone else),
Two things to note on this topic:
The new rule builder, currently in A/B testing and coming to everyone on Business/Enterprise next month, has an explicit area for setting conditions (i.e. based on current state).
In the current (now called 'classic") rule builder, while it’s far from obvious, many triggers actually work like conditions. Basically, if you include multiple triggers, then in many cases the first one acts as a true trigger and the rest of them act like conditions. For example, “If priority is set to High and task is moved to the Pending section” will actually behave as “If priority is set to High and task is in the Pending section”.