Sometimes I set the same action for different triggers. It would be great if I could manage them within one rule.
Context:
I created a rule to calculate a timerange of my Project object based on the Feature objects are linked to them. Automation recalculates it when I link them together and unlink them. These are two rules.
Moreover, I have to write another rule with the same action when timerange is modified on any Feature object.
I hope it makes sense
I agree, having more triggers (and chaining of triggers and conditionals and branching) in rules would be very helpful. I guess at the moment, you can still do this if you are willing to use a script.
In the example you gave, I am curious why you are not just using a formula field. They work really well in aggregating collection fields.
Good point, thanks for the hint.
Ok, I know why I did not use the formula field. I wanted to let project managers manually set the timeline until it is not filled with proper feature lists.
That makes sense. One of the tricks that I’ve used in these types of situations is to have both a manual field and formula field. I then create another formula field that either returns the manual field value or the formula field value based on the condition. So in your case while there are no features associated with the project, the time estimate is based on the manual field. When features are attached, you can use the count in an if statement and then return the value of your automatic formula field.
This is quite ugly and confusing for users, but when we get the ability to hide fields, including based on conditions, then this method will work quite well.
Not sure this is helpful but thought I mention it.
Thanks for bringing this up. It extends my thinking about these challenges.
and I agree, more and more technical fields are confusing on the UI