A flow is a visual representation of conditional branch logic that’s applied to your contacts once they enter it. Once a contact has entered a flow, they interact directly with its nodes. Nodes are composed of actions and Split Actions, and determine the length of a flow, which can be as short as a single node or as long as you want.
An action represents some action taken on behalf of your flow. Essentially, they’re commands that allow you to:
Send a Message (will send a message and/or media attachment to active contacts who reach that node in your flow)
Send a Message to Someone Else (outside the interaction taking place)
Adding Labels to Responses
Adding and Updating Contact Fields (with a value received in a response, for example)
Adding or Removing Contacts from a Group
Calling a Webhook
Sending an Email
Setting a Contact’s Preferred Language
Starting Another Flow
Starting Someone Else in a Flow
These actions that are executed immediately in order from top to bottom:
These are the pivot points in a flow, “splitting” it into new branches. They’re conditional statements that enable you to direct your contacts after evaluating:
an incoming message or recording
a request to a webhook
a Zapier flow event
an airtime transfer
the contact’s activity in a subflow
a contact field
a flow variable
a form field
random branch placement
their group membership
Anatomy of a Wait for Response Split Action
Split Actions are comprised of 5 inputs that allow you to construct a powerful conditional statement:
A – The type of RuleSet you’d like to create:
Wait for Response waits for an incoming message, then evaluates it against response rules. Optionally, you may choose to add a timer to Wait for Response action to send a reminder message to a flow participant after a period of inactivity, or create a ‘pause’ in a flow to stagger messages.
Call a Webhook calls a URL, passing it the flow context and, if the external service responds in JSON, makes the response available for reference using the variable @webhook. Flow context comprises the variables available in a given flow, including the active contact’s responses and contact information. This action contains two categories, Successful and Failed, to account for errors returned by the external service.
Call Zapier allows you to add a flow event at any node in a flow that corresponds with a Zapier flow event trigger. Once a contact reaches a flow event, all of their responses up to that node will be sent to Zapier, which can be configured to send that data to one of over 500 other apps without writing a single line of code. Use this guide to get started with Zapier.
Transfer Airtime enables you to transfer airtime to prepaid phones on over 400 networks across 100 countries. When a contact reaches a Transfer Airtime node, they’ll receive the amount you specify.
Enter a Flow enables you to start the active contact in a “child” flow at any step, then return them to the original “parent” flow. Two new conditions are introduced, Completed and Expired, giving you the ability to branch the active contact based on their activity in the child flow. Variables captured in the calling, or parent flow can be referenced using the @parent.[field] format, while variables captured in the child flow can be referenced using the @child.[field] format. More on flow variables here.
Split by contact field runs response rules against a value stored in a contact field (Name, Phone, etc.), referenced using the variable @contact.[variable-name], e.g. @contact.state.
Split by expression runs response rules against the result of an expression, such as @(REMOVE_FIRST_WORD(input.text)), which includes a function that removes the first word from the message last received, represented by the @input.text variable. Expressions can include a single variable, a single function, or a combination of variables and functions.
Split by flow result runs response rules against a value separated by a delimiter (a space, plus sign, or period), e.g. 1+2+3+4+5 (+ is the delimiter, while 1 is the first value, 2 is the second value, 3 is the third value, etc.). See this guide for more information.
Split randomly enables you to create as many evenly-distributed buckets as you’d like for the purpose of randomly branching a contact for an A/B test or the like. See this guide for more information on A/B testing.
B – Depending on the selected Split Action type, this is the value that response rules are evaluated against. This value, called an operand, represents a variable or expression. In the Split Action pictured above, if the message response indicates the operand is @input.text, or the incoming message.
C – The response rules that evaluate the selected operand. Response rules are executed from left to right. The first rule that matches takes effect and no other rules are evaluated after there is a match.
D – The option to set an amount of time after which a contact will be routed if they don’t respond. If the contact hasn’t responded in the amount of time you’ve chosen, they’ll be routed through a No response category. You can connect this category to a Send a Message action that encourages them to continue, or leave it unconnected to prompt an exit. See more info on timeouts here.
E – The value(s) your response rules will attempt to match against the operand. In the example above, we’ve created a Split Action that attempts to match the names of each of the northern states in Nigeria. With the Wait for Response action type selected and the has any of these words response rule selected, incoming responses will be placed in a category called “Northern States” if they match any of the words we’ve listed. This allows us to place the response “I live in Adamawa” in the “Northern States” category because the word “Adamawa” matches. Note that a flow will always match at least one response rule in a Split Action as the last response rules must always be a catch-all (placing contacts in the “Other”) category.
F – The category in which contacts are placed if the the operand matches the corresponding response rule. Categories are pathways from which connections can be drawn to new nodes, thus directing the contact onward. A contact’s passage through a category is represented in the analytics tab as a response.
G – The name given to the flow variable created and populated by the Wait for Response action. In the example above, the sample action will save the result of the evaluation to the flow variable @results.question_1_response.
Flows are states that your contacts will enter and exit. Once a contact enters a flow, (s)he becomes an active member of that flow until (s)he exits. Passage through a flow from entrance to exit–and all activity that takes place in between–constitutes a run. Runs and the activity that took place therein are displayed in flow results. Flow runs can be listed and started externally via the Flow Run API endpoint.
Active members are represented by the blue icon that appears on the top left corner of each node:
You can click the icon to send them a followup message:
Entering a Flow
Contacts can enter flows in any of the following ways:
You place them in a flow using the “Start Flow” button in the flow editor. You can check the Restart contacts who have already entered this flow setting to send to contacts who have already received a message from your flow. Additionally, the Interrupt contacts currently active in flows setting allows you to decide whether your flow will interrupt others. Note that if you interrupt a contact and remove them from another flow, they will not re-enter the other flow.
They’re placed in a flow triggered by a campaign event
They trigger a flow by sending a keyword
A contact triggers a flow by calling your channel’s phone number
A flow is triggered by a missed call from a contact
A contact triggers a flow by sending a message to your channel that isn’t handled elsewhere
Exiting a Flow
Contacts will exit flows when:
They complete a flow by passing through the final node
They pass through an unconnected node
They pass through a Start another Flow action
They’re expired from a flow after a certain period of inactivity, toggled within the “Update Flow_”_ dialogue within the flow editor:
Flow Membership Rules
Contacts may only interact with one flow at a time. _While a contact is active in a flow, their responses are handled solely by that flow until they exit or the run expires.