A flow is the central object in Intwixt. Users design flows by using the Intwixt visual designer. This particular flow sends a message in Slack, asking a user to grant access to their Box.com account.
Flows are stateful and can model long-running conversations, timeouts, wait conditions, and more. Statefulness keeps flows intuitive and readable, organizing even complex concepts with just a few activities.
A flow may contain multiple sub-processes to better organize the activities being orchestrated. For example, the flow above is comprised of 4 sub-processes: A, B, C, and D.
Sub-processes always begin with a single trigger that responds to outside events. When a trigger fires, the engine executes the activities that follow it one-by-one. Some of these activities call external APIs (like sending a message to Slack), while others aid in the running of the flow (like pausing the flow, calling another flow, or resuming a paused flow).
When the engine executes an activity in a flow, we refer to it as an "Activity Call". Intwixt flows support conditional statements and exceptions which means not not every activity defined in a flow will be executed when the flow is run.
For example, the flow shown above will call 6 activities if the user never responds to the Slack message and a timeout exception occurs (sub-flow A).
If the user starts the authorization session by clicking on the Slack message but then decides to cancel the authorization, only 9 activities will be called (sub-flows A, C, D).
If the user chooses to authorize the request then 12 total activities will be called (sub-flows A, B, D).