Skip to main content

Hello there,

I’ve been searching through the documentation to find how exactly is determined which process action step is taken in a process flow.

A new feature requires me to accurately predict (in a process) which process action is next in the flow. This would be easy if there is only one route to follow but when there are multiple, I need to check the values of the process step parameters.

Let’s say there are three routes in a process flow originating from a decision node. To determine which route will be taken we can check variables @thisStep_nextOne, @thisStep_nextTwo, @thisStep_stop.

This is how I thought it worked:

  • All routes set to 0 or lower are ignored
  • The route with the lowest number above 0 is selected
  • In case of a tie, the route with the lowest order_no is selected

This is giving me wrong results so I must be getting these logic rules wrong. Can anyone tell me how exactly this works?

Is there a reason you do not set the steps to different numbers either by default or by the decision node?

Is there a reason you do not set the steps to different numbers either by default or by the decision node?

I dynamically assign a process to all process actions in all flows for logging purposes. I cannot guarantee that all flows set the steps to different numbers since these could be developed by a colleague.

The following is automatically generated with each step variable by the SF: 

--Follow-up process actions. The number assigned to them will determine the order in which they are (depth first) executed. A value of null, 0 or a negative value means the process action will not be executed.

This implies the first rule (All routes set to 0 or lower are ignored) is true. 

After some research I think it likely that these rules are correct:

  • All routes set to null, 0 or lower are ignored
  • The route with the lowest number above 0 is selected
  • In case of a tie, the route with the lowest order_no is selected

It seems the problems I’m having with my code are caused by not accounting for the depth first functionality. It’s hard to predict the next step if the next step is “stop” which returns the flow to the previous point where two (or more) steps were set to not null and above 0.

Reply


Terms & ConditionsCookie settings