Routing Contacts with Splits

Split Actions function as pivotal junctures within a flow, dividing it into new branches. These conditional statements enable you to direct contacts based on evaluations of various inputs:

• An incoming message or audio recording

• A webhook request

• A Zapier flow event

• An airtime transfer

• Contact activity within a subflow

• Contact field values

• Flow variables

• Form field entries

• Custom expressions

• Randomized branch allocation

• Group membership status

Structure of a Wait for Response Split Action

Split Actions consist of multiple configurable components that form comprehensive conditional statements:

A – Action Type Selection

Choose from these action types:

• Wait for Response: Pauses for incoming messages and evaluates them against response rules. An optional timer can trigger reminder messages after periods of inactivity or exit contacts from the flow.

• Call a Webhook: Contacts a URL with flow context variables. Successful JSON responses become accessible via the @webhook variable. Includes ‘Successful’ and ‘Failed’ categories for error handling.

• Call Zapier: Creates flow events matching Zapier triggers. Contacts’ responses transmit to Zapier for integration with 500+ applications without coding. [See guide] for implementation details.

• Transfer Airtime: Sends airtime to prepaid devices across 400+ networks in 100 countries.

• Enter a Flow: Initiates child flows from parent flows, introducing ‘Completed’ and ‘Expired’ conditions. Parent variables reference as @parent.[field]; child variables as @child.[field]. More on flow variables here.

• Split by Contact Field: Applies response rules to values in contact fields (e.g., Name, Registration Date), referenced as @contact.[variable-name].

• Split by Expression: Evaluates expression results like @(REMOVE_FIRST_WORD(input.text)), which may contain variables, functions, or combinations.

• Split by Flow Result: Processes delimiter-separated values (spaces, plus signs, periods). [See guide] for details.

• Split Randomly: Creates evenly distributed groups for A/B testing or random branching. [See guide] for A/B testing information.

B – Operand Specification

The value against which response rules evaluate, typically a variable or expression. For message responses, this is commonly @input.text.

C –Response Rules

Sequentially evaluated rules where the first match determines the pathway. Rules process left to right until a match occurs.

D – Matching Values

The specific values response rules attempt to match. For example, with ‘has any of these words’ rule, “yeah” would match a “Yes” category containing similar affirmatives.

E – Category Assignment

Pathways contacts follow when operands match response rules. Category progression appears as responses in analytics.

F – Variable Storage

The flow variable name created by Wait for Response actions (e.g., @results.question_1_response).

G – Timeout Configuration