🪲 Rules not triggering when 'Number is' condition is a formula field

@Forum-team , I kindly ask that you escalate this issue to the product team to have a look - this one is definitely in the ā€˜not expected behaviour’ category :grimacing:

Not sure whether the introduction of (the very useful) formatting feature within formulas has caused this to break, or it was always the case but I will try and explain as best as possible in order for you to recreate, test, and hopefully fix since the use cases are numerous! :folded_hands:

One use case is to set a single-select field called ā€˜Status’ to display whether a task/milestone is ā€˜On track’ or ā€˜Off track’, based on whether the task’s due date has shifted compared to it’s ā€˜baseline’ (a date field). This rule would leverage a formula field called ā€˜Variance’ that would look like this, giving us an output in ā€˜days’.

Below is the rule using the ā€˜Number is’ condition to simply change the single-select field’s options. Looks fine, right? Well it doesn’t run at all :confused:

However, the rule runs perfectly fine when I replace the formula field with a simple number field. So my hunch is that there is something not working correctly with formula fields.

I think the problem is in the way my ā€˜Variance’ formula field is written - it basically converts the native weeks/days output into minutes (by using the +0) and then divides the minutes within a day (1,440) to get the output in days, formatted as such (which I don’t think is the problem):



Call this a hacked formula?

Side note, the API reveals that the values of the formula field are whole numbers and nothing strange between the display value and number value.

I’ve noticed that if you create such as formula (which includes dates) but without applying the formatting immediately (before you hit ā€˜Create field’) then you will not be able to format it later. This is what you see if you try to format later, or if you try and format a simple Due date - Today formula upon creation:

Note, such formulas are not available in a Rule’s ā€˜Number is’ condition. So at this point, I’m thinking perhaps I’ve done something Asana does not want me to - I’ve made a ā€˜hacked’ formula (that contains date fields), available to be used in the ā€˜Number is’ condition of a rule. But my argument is, since Asana lets me format the formula into a ā€˜number of days’ value, then why not let me use this number in the check if ā€˜Number is’ condition in the rule?
It would be awesome if it could! Please don’t tell me this is expected behaviour :folded_hands:

Further testing:
I even tried to place the ā€˜Variance’ formula into another formula and instead use that in the rule, but neither that worked with the rule.

I also tried a simple formula field with a fixed number as per below - the rule triggered correctly each time I changed the formula, concluding that it is not formula fields in general, only my particular ā€˜hacked’ formula:

I started getting somewhere when I tried adding more ā€˜Whens’ and changed the conditions to include an ā€˜otherwise’ instead and this actually worked, but only once, when the variance value was initially set/populated. After the variance field (and status field) was set, the rule did not seem to run again. :confused:


And strangely enough, the above rule worked perfectly when the ā€˜Baseline date’ (date field) was changed (but not when the Due date field is changed). So is there something wrong with the due date updating the formula field’s value or triggering the rule?! :exploding_head:
Something is definitely not right :grimacing:

Ideal solve:
Clearly, this would all be solved if I didn’t need to create this ā€˜hacked’ formula field and instead Asana would allow formatting of formulas that contain any date related fields, including created on, today, etc. so that they can be used in the ā€˜Number is’ condition of rules.

6 Likes

Something seems fishy and you certainly did a thorough job laying it out as best you could. I hope it will be escalated and can be improved, because this would be useful and until addressed will continue to trip up others similarly.

Thanks,

Larry

3 Likes

Hello @Richard_Sather and @lpb - I have gone ahead and reported this as a bug to our team. I will respond once I have heard back from the team.

4 Likes

Hi @Alex_Christensen , thank you for reporting this to the team. I take it you have not received any feedback yet?

1 Like

Hello @Richard_Sather, I have not heard anything back as of yet. I have the task saved and will update once the team has information to share.

2 Likes

Hi @Forum-team , just checking in case we have any updates? This is a serious bug and is breaking workflows and big gap in the ā€˜Number is’ condition, making formula fields unusable. They appear to trigger when the number is set but not when it is changed.

Thanks!

1 Like

Hi @Forum-team , kindly asking for this to be escalated again and looking for an update.
This bug is painful and has broken several workflows that previously worked absolutely fine.

In essence, when a formula field is changed it does no longer trigger a rule :confused:

Cc @Garrett_Knoll (I know it’s not your area, but hoping you can push this along!)

1 Like

Thanks for following up again, @Richard_Sather. You’re right to be frustrated. This is a known issue, and we haven’t done a good job of keeping you updated or moving it forward yet. I’ve flagged it again with the team and asked for clarity on prioritization, and I’ll keep you informed as we learn more.

3 Likes

Lots of great recording, @Richard_Sather .
I found this thread while looking for issues related to ā€œNumber field is changedā€ rule trigger not triggering when the field is a formula. Definitely buggy.

1 Like

Thanks, @Adam-Involute. Hoping this can get patched up soon! :crossed_fingers:

Another issue related to triggers of formula fields here:

Essentially, when a trigger is a formula field which is formatted as a date, it does not trigger a rule when that date value is simply changed.

@Forum-team , @Emily_Roman , I’m kindly asking for yet another escalation as this is a considerable loss of what should be considered expected functionality.
CC: @Julio_Buendia

2 Likes

Hi @Richard_Sather , we’re currently looking into this and will keep you updated as we make progress. Thank you!

3 Likes