Articles on: Flows

Routing Contacts with Splits

Split Actions 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

an expression

random branch placement

their group membership


Anatomy of a Wait for Response Split Action








Split Actions are comprised of inputs that allow you to construct a powerful conditional statement:

A - The type of action 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 the Wait for Response action to send a reminder message to a flow participant after a period of inactivity or exit them from the flow.


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 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, Registration Date, 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 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 responses 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 "Yes" or "No" if they match any of the words we've listed. This allows us to place the response "yeah" in the "Yes" category because the word "yeah" 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.


E - 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.




F - 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.

G - 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.

Updated on: 06/09/2023

Was this article helpful?

Share your feedback

Cancel

Thank you!