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) “________”
Etc.
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:
+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.
Use case:
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.
Desirable:
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”
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”.
We came into a big problem with the new rule builder. Hopefully I can explain myself:
We have built a system to trigger Department Requests (Subtasks) for an Event (Task) when a Department (Option) is selected in the Department Request custom field (Multi Select) of the Event (Task)
Previously, with the automation in the screenshot below, every time you would select one department (Multi Select Option) it would create just the subtask for that department, even if other departments/options were already selected (we have one rule for each department to create a specific subtask)
With the new rule builder (see screenshot below), when you select an option in the department requests, and you have other options already selected, it triggers all the other rules for the other departments since it responds to “Department Requests is changed” trigger. With this, it creates new subtasks even for the options that has not been changed.
I know it is complicated to explain the system we have over a post but this update completely destroys what we have been using for almost a whole year.
Hi @Esteban_Giannini , from what I gather, I think that your second trigger should be removed. Or possibly, you should (be able to) change the OR to AND (between your triggers).
Unfortunately, when the second trigger (Department Requests is changed) is removed, the rule no longer triggers when you make a change if the task is already in the project.
As for changing the OR to AND, it seems that this is not possible on the trigger side. Apparently, the new rule builder doesn’t have the capability for it.
@Esteban_Giannini you do seem to have found an edge case in the behavior of the new rule builder. Because it looks to be a regression from the old (classic) rule builder, I’m moving your report to the Critical Bugs forum section.
Hi everyone, thank you for moving this case to the Bugs Section. I’ve escalated this report to our Developers to see if this is expected and if there’s a workaround to share. As soon as I have an update I’ll let you know!
Hi @Vanessa_N - Just wanted to circle back to see if there has been any updates on this? We use this workflow multiple times a day and every day that goes by it is creating frustration in our organization. Hopefully there is some workaround. Thanks!
Right, I should have mentioned - once you start building a rule in the new rule builder, that option is no longer available; but you can revert with a blank new rule showing.
Our Developers have confirmed that this is unfortunately a limitation in the new rule builder, but they plan to roll out a solution in the near future.
As a non-ideal workaround, you can opt-out of the new rule builder, which will allow you to continue to use the old rule builder. Instructions for opting in and out are in this guide article.
