Expectation:
Note what happens when the āBudget is approvedā it should set the custom status to āIn developmentā. And whenever the status is set to āIn developmentā, it should set assignee to Maria. The result should end with Maria being the assignee, but it doesnāt work.
Problem:
When I set āBudget is approvedā then the custom status is set to āIn developmentā but then it does not trigger again to carry out the actions to set Maria as the assignee. The task remains assigned to the previous assignee, in this case, Charlie.
Test:
Set to āFor clarificationā ā assign to George
@Forum-team , could you kindly escalate this as a bug please? I have tested it in two environments now and it is not following the expected behaviour - if this was using a single-select field as a āStatusā it would work just fine.
The workaround would be to apply the same actions in the āBudget approvalā condition as per the āIn developmentā branch (in this case, add the action āset Maria as the assigneeā) but there really should be no need for this.
I have known this for a long time and thought it was expected, to avoid a rule triggering a rule, and potentially having a loop. If you create 4 rules, instead of one with 4 branches, I believe it works
Are you saying the same applies to rules using a single-select custom field?
In that case, that would make sense and if that is āexpected behaviourā then I guess this is not a bug and instead consistent with the same behaviour of a when using a field.
Would still be interested in what the Product team have to say
Yes. I saw it when I tried to get a task to move automatically from section 1 to section 2 to section 3 etc and each section had its own actions. It stopped after the first move because the rule wouldnāt run a second time.
Considering the behavior we are observing, and I dealt with the same thing in another complicated workflow I was trying to set up with a lot of rules working together, Iām fairly confident that when a rule run begins, thereās a data object in the code that tracks the entire sequence of all the rule runs and all the actions associated with that series of triggers and actions, even if it stretches across rules ā letās call it a āRule Run Batchā. I donāt see any evidence of it in the API, but it makes sense that there would be something like a āRule Run Batchā with an associated gid. And every rule can only run once per rule run batch. Then hypothetically if the first rule in a series of five chained rules is triggered again by a rule run batch with a gid that it has already seen, it wonāt run again.
This came after experimenting using a sequence of 5 sequential rules that all triggered each other and the 5th went back and re triggered the first rule which then did not run again.
Just a hypothesis, but Iām guessing thatās how itās all structured.
Thatās a really interesting hypothesis, @Bryan_TeamKickstart , which makes total sense.
@Bastien_Siebman , I think this would make an interesting addition to your list of ābutsā. i.e:
āA rule can trigger another rule but not the same rule within a chain of triggered rulesā or something along those lines.
Similarly, and more in line with this thread, āA rule condition of a custom field option can set another option of the same custom field, but it will not run the rule again if that option is triggering another condition - the same applies to custom task statusesā - makes sense?
We encountered this limitation approximately a year ago while attempting to create a task that would trigger the same rule. It appears to be a restriction designed to prevent loops.
