Interestingly, while we were testing/experimenting, we found that we can get the rule to work just fine by simply ‘refreshing’ the variables in the relevant rule. To be specific; we go into the relevant part of the rule in each newly-created project, delete (task name) and (category) and then simply add those variables back in again (using the ‘+’).
Hi @Alex_Berger, thanks for reporting this! I have gone ahead and escalated it to our product team so we can investigate further. I will let you know once I have an update!
Let me know if you have any questions in the meantime
Just a quick note that may help @Alex_Berger. Is the form the only way you are submitting tasks? If so you can configure the submission titles in the settings of the form.
When we configure the submission titles in the form settings, it separates the variables with a comma (e.g. ‘name, category’) and we’ve always used a hyphen. It’s not a huge deal obviously, but if we can get the new task title rule to work as we hope, we’ll be able to continue on with the hyphens we all know and love haha.
Of course (cc: @Emily_Roman), it would of course be amazing to have additional options to customize the syntax of submission titles in a form’s settings (although I’m sure there’s a thread on this this already)!
@Emily_Roman running into similar issue, when creating a project from a template that has a rule to update Task Titles when a custom field is changed, we then update the custom fields in bulk in order (1, 2, 3)
Custom_field_1
Custom_field_2
Custom_field_3
Rule: When Custom_field_3 is changed, set task title to Custom_field_1 Custom_field 2 - Task Name
Result is: [invalid value] [invalid value] - [invalid value]
I triggered the rule off of Custom_field_3, thinking that maybe there was a “race” issue where the rule was running before Custom_field_1 and Custom_field_2 were done being written to the database. But seeing that another person is having similar issue, this may not be the case.