The SetStateActivity can be used in state machine workflows only.

The SetStateActivity only provides transitions to leaf StateActivity activities (a StateActivity that does not contain other StateActivity activities).

The SetStateActivity only provides transitions between two StateActivity classes and does not support StateActivity to parent StateActivity transitions or any other combination.

The SetStateActivity has to be a leaf node within the activity tree of an event handler.

There can be more than one SetStateActivity but all the activities must be leaf nodes.

SetStateActivity is always the last activity in the run path of a EventDrivenActivity activity.

The TargetStateName property of a SetStateActivity cannot be changed at runtime. Use the DynamicSetStateActivity if that kind of behavior is needed.

When working with state machine workflow's the SetStateActivity is one of the more important activities to use. The main reason is that is the one used to transition from one state to another. You can actually transition state in a different way as well using the StateMachineWorkflowInstance.SetState() function but the SetStateActivity is by far the most often used.

One of the cool features of the SetStateActivity that may not be immediately obvious is the fact that it doesn't do the state switch immediately. Instead it saved the new target start in an internal property, named NextStateName on the StateMachineExecutionState type to be exact, and only does the state switch when the current EventDrivenActivity or StateInitializationActivity is finished. And just to be clear those are the only two activities where you can use a SetStateActivity.

So the cool part is that you don't need to have the SetStateActivity right at the bottom of the EventDrivenActivity but it can be anywhere in the execution flow. Something that might make the execution logic quite a bit easier.

And the second cool behavior is that you can actually execute multiple SetStateActivity objects with different TargetStateName definitions and only the last one will be executed. Again something that might make the logic quite a bit simple as you can set a default TargetStateName at the beginning of your and make changes to the target as exceptional cases arise.

Both of these behaviors are especially important as the TargetStateName is a meta property, meaning it cannot be changed at runtime but only at design time. So the option of dynamically changing the SetStateActivity doesn't really exist.