Entry Payload and Routes

The result of running a flow


Creating a flow is just defining the blueprint for a business flow.

Executing a flow is essentially running the flow's snapshot with a certain input and in a certain environment.

Entry Payload

A flow execution can be triggered with a certain input.

Example 1: A flow which determines the customer's age is triggered, with the 'customer' object being the entryPayload for the execution (the Entry Argument for the flow execution).

A flow with entryPayload that contains a JSON with customer data

In this example, the flow was executed with an entryPayload in the form of a JSON object, which contains customer data, describing a certain customer named Anna, and her age.

This entryPayload information is accessible by every state in the flow during execution.


To this point we've looked at simple flows which only have 1 execution route. Meaning every state was connected to only 1 possible true state.

Our condition state in the example above "State 2" has only one connection for 'Yes!', and one connection for 'No!'. It is impossible for both of these connections to be activated as a customer cannot be both above 18 years old and below 18 years old at the same time.

Because of that, only one, simple execution route is possible, no matter what the input is.

But what if we have more complex flows, that have more than one connection from a certain state?

Let's take a look at the same example from above, properly implemented in STATEWIZE with a few changes:

Complex flow

In this example, we have the following logic implemented:

  1. Check person's age

  2. If person is an adult

    3. Make a payment 4. (in parallel)

    • Send email

    • Send SMS

    • Notify (push)

      5. Print result

Considering this flow, the complexity starts from the "pay" state; Upon the successful execution of the "pay" state, there are 3 states that will be executed in parallel. This means that the final state of the flow, "print_res", will be called 3 times:

  1. pay -> send_email -> print_res

  2. pay -> send_sms -> print_res

  3. pay -> notify -> print_res

This is because there are 3 routes that one can take in order to reach "print_res".

Here is how the real execution will look like:

Execution in real time

You can see the canvas changing colours to indicate the execution progress. The final state, "print_res", was indeed called 3 times following the 3 possible routes:

Looking at the routes

Each state in this execution, except "print_res", was executed exactly once. Every route mentions all previous states in itself just for clarity, so you could look at a route as a whole.

The importance of routes

Since every state can be executed under different routes (based on your flow), you might be interested in knowing what the output of state "print_res" was under each of the routes that caused it to execute. These output might be different, and being able to examining each and every one independently gives you absolute transparency into the execution process.

So no matter what happened in real life, you will always be able to trace back, investigate and understand what happened, and why.