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.
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).
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:
In this example, we have the following logic implemented:
Check person's age
If person is an adult
3. Make a payment 4. (in parallel)
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:
pay -> send_email -> print_res
pay -> send_sms -> print_res
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:
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:
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.