State Machine Execution Sequence

Anyone knows the correct answer to this question and can explain why please?

@Palaniyappan perhaps u can help with this

Maybe this can help

  1. Activity in entry section are performed

  2. Activity inexit section are performed

  3. Trigger condition are evaluated

  4. Activity in trigger action are performed

I think this is the order

1 Like

A state can have an Entry and an Exit action. (A state configured as a final state may have only an entry action). When a workflow instance enters a state, any activities in the entry action execute. When the entry action is complete, the triggers for the state’s transitions are scheduled. When a transition to another state is confirmed, the activities in the exit action are executed, even if the state transitions back to the same state. After the exit action completes, the activities in the transition’s action execute, and then the new state is transitioned to, and its entry actions are scheduled.

1 Like


As you can see, I created a very simple state machine, in one state I just put log messages to track the order. According to this the answer is:


  1. Entry section
  2. Trigger action
  3. Trigger conditions are evaluated
  4. Exit section

If you need clear explanation why it works so, then search for “UiPath State machine UiPath RPA” in youtube, you can see the first video uploaded by the user “UiPathRPA”

@NIVED_NAMBIAR @Surya_Narayana_Korivipadu @jack.chan @Umut_G @dion.chan @Brett_Gates @Parth_Doshi @Priyanka_Bhalere @nisargkadam23 @Ishmeet_Bindra

How to convert sequence into state machine ?
what are the conditions to observe to convert ?
Please share one example done with both sequence and state machines

Refer this link

UiPath State Machine| State Machine Workflow UiPath | UiPathRPA

UiPath State Machine| State Machine Workflow UiPath | UiPathRPA

](UiPath State Machine| State Machine Workflow UiPath | UiPathRPA - YouTube)

You can find good explanation about state machine with examples. Take a simple example from this tutorial and try to build a state machine and also try to build the same thing with a sequence. Relate that tutorial to traffic lights scenario. You’ll understand it better.

But I don’t suggest using state machines when your process is simple and linear. You can simply take a sequence. Check the process complexity and use state machine only if it fits the state machine logic.

1 Like

This answer is incorrect. I validated Umut’s proof.

  1. State Entry Action
  2. Trigger Evaluation
  3. State Exit Action
  4. Trigger Action

What’s this Umut’s proof?

In the state machine transition, they gave “Trigger” and “Action”

I assumed, “Action” as trigger action and so I gave

  1. Entry
    2.Trigger conditions are evaluated
  2. Exit
  3. Trigger Action

But if the “Trigger” is trigger action, then

  1. Entry
  2. Trigger Action
  3. Trigger conditons are evaluated
  4. Exit

So I think the question given by UiPath practice test , itself is not clear.

See entry in this thread from Umut_G on March 26. I ran the same test and go the same results as Umut.

Got it. But if we carefully observe this image, the log message inside the “Action” part, it is given as “T1 condition”

The part mentioned in T1 Condition, 1=1 is the condition but not the “Action” part. The messages in the “Log Message” activities are not properly written in Umut’s post

@Surya_Narayana_Korivipadu is right and also @Umut_G 's screenshot does not show otherwise, on the contrary.

It’s a matter of semantics, mostly, combined with a tricky formulated question + very confusing naming conventions for Transition sections. :slight_smile:
The Transition Condition is actually being evaluated between log messages “T1 trigger” and “exit”.

Here’s a rather detailed logging of what’s happening (my Value gets incremented in Trigger Action):

The Transition Condition is being evaluated each time Trigger Action activities get executed, but you can only observe that if you log activities:

So the correct answer will be:

  1. Activities in the Entry section are performed
  2. Activities in Trigger Action are performed
  3. Trigger Conditions are evaluated (if False repeat step 2 until True)
  4. Activities in Exit section are performed.

if there was a 5th option, that will be:

  1. Activities in the Condition Action branch are performed.

I know, they could have named those differently… :smile:


Perfect explanation @Marius_Vrancianu

The sequence in which state machine is executed is

  1. Entry section is performed
  2. Then the Trigger condition is evaluated
  3. Then it executes the exit section
  4. At last the if trigger condition is true the trigger action is performed

bryansenter is correct

1 Like

My test shows this is the order:

1 Entry →
2 Trigger (activities in the top container)->
3 Check trigger condition (until 1 of them is true, if not the trigger runs again) →
4 Exit - >
5 action
(for whichever branch was chosen by the true condition)

See this file, (I only added 1 condition, you can make input with 1-2-3 option, and make selection=1 or 2 or 3 make 3 conditions with 3 different actions if you wish, or 3 different exists… if you understand this:

StateMachine.xaml (9.6 KB)

Run this file, and type false false then true. Then check Output window, so you see condition was checked after input because cond default was True, if it was checked before the input it would do the action and exit, but its not so the trigger part must run first:


For each state there can be multiple “trigger condition” + actions but only ONE trigger (activities)"

So the answer for the original question:


Or in order:

  1. Entry section
    (The trigger container would run here between 1 and 2 if not empty, until 1 branch is true)
  2. Conditions evaluated (true one is chosen and the action will run of that branch)
  3. Exit
  4. Trigger Action

the trigger part is where you can ‘modify’ the condition, for example see my post,
you can do an input dialog, chose the menu options
int32 menuoption=1,2,3 then make trigger conditions+ actions based on the value of menuoption
menuoption=1, log you selected 1
menuoption=2, log you selected 2…
if the menu does not exist trigger part runs again (try the file I uploaded in my other reply)

See my other reply where I did an in-depth analysis of verbose level logs.

I’ve done a verbose level log analysis with super secret developer tool (Paint), so, the order:

  1. previous state →
  2. State Entry
  3. Trigger sequence block
  4. Trigger Condition evaluation
  5. Exit
  6. Action
  7. → next state

[edit: on the picture I say “It was false so 1-2 repeats” but its 2-3, this was a mistake]

It all makes % sense if you can design a nice state machine, some scenarios, like the elevator is good example (though it can get pretty complicated to design a “collector” type elevator that stops at every levels when people go same direction, etc.),
you probably have to do multiple state machines for this, one just for the elevator motor, the elevator door, one for the elevator “box” statuses itself, etc. ), etc.

A simple version would be something like, creating only few states like:

state1: elevator moving
state2: elevator stops + door opens
state3: elevator engine start up (forward or reverse, this can be 2 separate state too)

And then:

  1. (previous state) Elevator moving, exit this state when it stops and doors open →
  2. State Entry State: Stopped elevator with opened doors or even you could open the door in the “Entry” phase itself (also you can enter the elevator, no pun intended)
  3. State Trigger sequence block (wait until a button is pressed)
  4. State Condition evaluation: “level” button was pressed?
  5. State Exit (to Elevator engine start up state)
  6. State Action depends how the state machine was designed, this can for example: close the doors (or invoke a new door state machine with “close” argument), or it can just announce on the speaker “Doors are closing”, so stuff that needs to be done when exiting this state
  7. ->next state elevator motor start up state

(disclaimer: this example is pretty poorly designed, probably makes no sense, I just wanted to illustrate why there is trigger sequence block, trigger condition, action… and why they are executed in a “weird looking” order)

Hi @Robert_Lovasz,

I always find it fascinating when someone going in deep just for the sake of it :slight_smile:

We applaud your efforts, I suggest you add a delay in each state such that the log time stamps are unique for each entry/exit of the order.

This is to eliminate any doubts regarding the lag or a lack of it in Nlog. Sometimes UiPath / Nlog log the n+1 stage before the nth stage. With a delay you will avoid this unwanted behaviour. Uniform delay in each entry/exits.


1 Like

The correct sequence is:
1: Activities in The Entry Section are Performed
2: Trigger Condition are evaluated
3: Activities in the Exit section are Performed
4: Activates in the trigger Action are performed

1 Like