Skip to content

State Machine States

Mikołaj Milewski edited this page Oct 27, 2026 · 1 revision

States

State represents stable configuration of State Machine.

In general, a State consists of:

  • Name, uniquely identifying State within State Machine,
  • Parent State, if State is a substate of Composite State or Orthogonal State,
  • OnEntry, logic that is executed when a State is entered,
  • OnExit, logic that is executed when a State is exited,
  • OnInitialize, logic that is executed when a composite or orthogonal State initializes its child configuration,
  • OnFinalize, logic that is executed when a composite or orthogonal State reaches its final configuration,
  • Set of outgoing Transitions.

Types of States

There are four types of States:

  1. Simple State that can have any number of outgoing Transitions,
  2. Composite State that can have any number of outgoing Transitions and any number of States (called its substates) having their own Transitions,
  3. Orthogonal State that is similar to Composite State, but its substates are grouped in any number of Regions that are considered orthogonal / parallel,
  4. Final State that marks the end of State's flow and can't have any outgoing Transitions nor OnEntry / OnExit logic.

Definition

UML notation of two States connected by Transition:

stateDiagram-v2
SourceState --> TargetState
Loading

Equivalent Stateflows notation of States:

Lambda style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddState("SourceState", b => b
        .AddDefaultTransition("TargetState")
    )
    .AddState("TargetState")

Using lambda style means that States are represented by string names passed as parameters to Add*State methods.

Typed style

Definition fragment (inside the builder callback):

    /* fragment of State Machine definition */
    .AddState<SourceState>(b => b
        .AddDefaultTransition<TargetState>()
    )
    .AddState<TargetState>()

Using typed style means that States are represented by classes referenced in typed overloads of Add*State methods. Such classes must implement the appropriate interfaces; see State, Composite State, and Orthogonal State.

Logic

There are two places where logic can be injected into State (except Final State), both optional:

  1. OnEntry:
    • is called whenever State is entered,
    • can cause side effects.
  2. OnExit:
    • is called whenever State is exited,
    • can cause side effects.

The way of adding logic to States varies by declaration style; examples are available on the State page.

For Composite and Orthogonal States, there are two additional logic units:

  1. OnInitialize:
  2. OnFinalize:

Deferring Events

Any State can declare event types to defer with AddDeferredEvent<TEvent>(). Matching deferrals are evaluated before normal transition processing; when a deferral guard passes, the event is retained and not offered to transitions in the current configuration. After later event processing, Stateflows reevaluates deferred events and processes a queued event normally once no active state defers it.

Deferrals declared on active ancestors and active states in orthogonal regions also apply. Optional deferral guards can make the decision conditional on the event payload or context. Completion, Finalize, and time events cannot be deferred. For details and examples, see In-State Event Deferrals.

Overview
Installation
Runtimes
   Orleans runtime
Concepts
   Events and Structural Events
   Messaging Patterns
   Validation
   Scheduling
   Observability
Behaviors
   Behavior Values
   Dependency Injection
   Behavioral Groups
   State Machines
       Concepts
           State Identity
           In-State Event Deferrals
           Evaluation of Transitions
           Exception Handling
       Building blocks
           Regions
           States
               State
               Composite State
               Orthogonal State
               Final State
           Pseudostates
               Choice
               Junction
               Fork
               Join
               History
           Transitions
               Transition
               Default Transition
               Internal Transition
   Activities
       Concepts
           Exception Handling
           Implicit Fork and Join
           Tokens
       Building blocks
           Nodes
               Action Node
               Decision Node
               Merge Node
               Initial Node
               Final Node
               Input Node
               Output Node
               Fork Node
               Join Node
               Accept Event Action Node
               Send Event Action Node
               Publish Event Action Node
               Time Event Action Node
               Data Store Node
               Structured Activity Node
               Iterative Activity Node
               Parallel Activity Node
           Flows
               Data Flow
               Control Flow
   Actions
   Entities
       Fields
       Mutations
       Projections
Extensions
   ClearScript
   FluentValidation
   JSON definitions
   Minimal APIs
   OneOf
   OpenTelemetry
   PlantUML
   Scheduling

Clone this wiki locally