Contents
- Where conditions are used
- Condition format
- Data sources for conditions
- Operators
- Step conditions
- Conditional transitions via the Go to another step action
- Conditional reminder targets
- Signal dependencies and steps triggered by signals
- Conditional actions inside a step
Conditions are a universal format of rules that the system uses to control the availability of scenario steps, the order in which actions inside a step run, and the dependencies between signals.
These are not instructions for the agent but deterministic checks that the system itself performs based on the set of data related to the conversation with the client and the environment the agent works in.
Instead of describing long conditional rules "If the client asks for X, then do Y" in the prompt, it is better to move them into the scenario settings. This way the agent does not have to parse a complex construction of rules anew each time; the system itself limits the available options and leads the scenario down the right branch.
The condition system is intentionally made universal. The same rule format can work with scenario step fields, signal values, schedules, CRM client data, the conversation state, and configuration data. This way conditions become a single tool for managing the scenario: the same rule logic is applied in different parts of the agent's setup.
Where conditions are used
| Place | Purpose | Notes |
|---|---|---|
| Step conditions | Control whether a scenario step is available at the current moment | Apply to steps with different triggers, not only to steps the agent chooses itself |
| Dependencies between signals | Control which signals are available to the agent for analysis | Let you open more precise signals only after the previous conditions are met |
| Steps triggered by signals | Start a hidden scenario step when the signal values match the conditions | Used for an automatic reaction to the state of the conversation |
| Conditional actions inside a step | Control the order in which actions run after a step is called | Let you skip an action, run only part of the actions, stop or block the step |
| Transitions between scenario steps | Before the transition, the system checks whether the target step is available | If the target step's conditions are not met, no transition task is created for the agent |
| Creating reminders | Before a reminder is created, the system checks whether the target step is available | If the target step's conditions are not met, the reminder is not created |
Conditions are not meant to hint to the agent when to apply a visible step. The scenario step has its own instructions, visible to the agent, for that. Conditions are needed when the system must limit the availability of a step, action, signal, or transition by checkable data.
Condition format
A set of conditions consists of one or more rules. Each rule specifies:
- the data source the system should take the value from;
- the name of the value or the path to it inside the chosen source;
- the comparison operator;
- the expected value.
For example, a rule might mean: take the value of the "client's mood" signal, compare it with the "irritated" option, and consider the condition met only on a match.
If a condition contains several rules, they are linked in one of two ways:
and— all rules must be met;or— it is enough for at least one rule to be met.
The expected value in conditions is stored as text. For "yes/no" values, the strings "true" and "false" are usually used.
If the value name is specified incorrectly or the system could not find the needed data, the checked value is considered missing. This is important to bear in mind with the empty operator: an error in the path can look like a genuinely empty value and open the wrong scenario branch.
Data sources for conditions
The data source determines where the system takes the value to check from. In a single set of conditions you can check different data sources: the meaning-related characteristics of the conversation (signals), the fields of the current called step, the saved scenario data, the parameters of the current event, the client's CRM data, and schedules.
| Data source | Where it takes the value from | What is specified in the condition | When to use |
|---|---|---|---|
| Step data | The current step's data, filled in by the agent | A scenario step variable | When the further actions depend on a value the agent passed in this same step |
| Signals | The current signal value | The signal name from the list | When the rule depends on the meaning of the conversation: mood, intent, risk, a repeated request |
| State | The saved scenario data | Variables used earlier in the Update state variable action |
When the value was collected earlier and should influence the further scenario in this conversation |
| Parameters | The data of the current agent run | The parameter name from the list | When the rule depends on the current event: the message, attachments, channel, UTM, or the dialog owner |
| Customer data | The client's CRM profile | A field from the client data | When the rule depends on stable client data: tags, custom fields, contacts, manager, or segment |
| Schedules | The CRM's working hours or the agent's custom schedule | The schedule name from the list | When the rule depends on the current time |
The "Step data" source is especially important to keep in mind. Such data appears only after the agent has called a specific step and passed the values of its variables. So it can be used in conditional actions inside this same step, but cannot be used for step visibility conditions, signal dependencies, or other checks that run before the step is called.
The Step data source
The "Step data" source is used for branching inside an already-called step. It takes the values of the variables the agent passed when running this step and lets you decide, based on them, which actions to perform next.
This source is not suitable for step visibility conditions and other checks that run in advance. Before the step is called, the system does not yet have the values of its variables, so they can be checked only in the conditional actions inside the step itself.
Example: a step has a decision variable, into which the agent passes the decision about the further scenario:
continue— continue the standard scenariooperator— hand the dialog over to a managerstop— stop this branch
If the variable value equals operator, a condition can perform the actions to hand the dialog over to a manager. If the value equals stop, another condition can stop the further actions in this branch. The continue value can be left as the ordinary execution path without a separate condition.
The Signals source
The "Signals" source uses the signal values that the system determines from the conversation with the client. A signal holds a separate characteristic of the conversation: for example, the client's mood, lead type, interest in the product, or the need for escalation. Conditions can rely on these characteristics to show the needed steps, start associated scenario steps, open other signals, or direct the scenario down the appropriate branch.
Signal values are preserved within an open dialog and are not reset after each reply from the agent. So a condition can fire not only on a signal found right now, but also on a value that was determined earlier in this same conversation. When the dialog is closed, the signal values are cleared, and a new dialog starts without the previously found signals. While the dialog is open, a signal value can change or reset if the further conversation changed the context; this needs to be taken into account when composing conditions that rely on signals.
Hidden steps associated with signals are started when a signal gets the value specified in the step's conditions. Such a step can also have additional conditions from other sources: before starting, the system checks the whole set of rules. If the signal value has not changed, the associated hidden step is not started again. If the signal was first reset and then got a suitable value again, the step can start once more.
For example, if the "Client's mood" signal got the value "irritated", a condition can start a scenario step to escalate the dialog: add an instruction for the agent to apologise carefully, offer a manager's help, or hand the dialog over to a responsible employee.
The State source
State is the scenario's internal memory within the current conversation with the client. It is convenient for storing values that do not need to be saved in the CRM but that should influence the further work of the scenario: the chosen service type, the qualification result, the delivery city, a temporary branching flag, or another intermediate characteristic.
State values are written via the Update state variable action. It can save a value the agent passed into the current step's variable, or a predefined fixed value. When configuring the action, the user specifies the state variable name.
To use the value in conditions later, it must first be explicitly written in one of the scenario steps. After that, when the "State" source is chosen, the interface will show this variable in the list of available values, and it can be referenced in the conditions of other steps or actions.
Unlike signals, state is not cleared automatically when the dialog is closed. The saved values remain in the scenario until another action overwrites or resets them. So for temporary values you need to think through the lifecycle in advance: when the value is written, where it is used, and at what point it needs to be cleared so that it does not influence later, unrelated parts of the scenario.
For example, after sending the greeting, the scenario can write the greeting_sent variable with the value "true" into the state. Other conditions will understand that the greeting has already been sent and will not open the greeting step again. When this flag is no longer needed, a separate step can write an empty string into greeting_sent. After that, the conditions will again consider the variable empty and will be able to open the greeting in the needed scenario.
The Parameters source
The "Parameters" source is used for conditions that depend on the current event and the dialog environment: the message text, the channel, the sender, or the dialog owner. In the interface, the available parameters are chosen from a fixed list, grouped into "Message", "Channel", and "Responsible".
| Parameter | What it checks | What to usually compare with | When to use |
|---|---|---|---|
| Message → Message text | The text of the last message | An exact phrase, command, or fragment of text | When you need to react to text known in advance: a manager command, a stop word, a service phrase, or a message template |
| Channel → Channel type | The type of channel the conversation came from | The channel type code, for example whatsapp, telegram, consultant, fbmessenger, instagram, viber, max |
When the scenario should differ for different types of communication channels |
| Channel → Channel | The name of a specific channel | The exact channel name in the system | When you need to configure behaviour for a specific connected channel, not for the whole channel type |
| Responsible → Agent is responsible | Whether the current agent is assigned as the dialog owner | true — the dialog is assigned to this agent, false — it is not |
When a step or action should run only if the dialog is currently with this agent. Used to protect actions that cannot be performed without owning the dialog |
Besides those in the example, the parameter list also includes: under "Message", "Sender type" and "Sender phone"; under "Responsible", "Responsible type" and "Responsible name".
Parameters are suitable for stable facts of the current event. If the rule depends not on the event itself but on the meaning of the conversation, it is better to use a signal. For example, an exact phrase in a message can be checked via the "Message text" parameter, while a client's request to call a manager is more reliably determined via a signal.
The Customer data source
The "Customer data" source uses the client's CRM profile linked to the current chat. These values differ from the scenario state: they belong to the client card in the CRM and can be used across different dialogs, not only within the current scenario branch.
In the interface, the available values are grouped by the sections of the client card.
| Group | What values are available |
|---|---|
| Customer | Bad customer, VIP customer, Customer external ID, Customer manager, Date of unsubscription, Birthday, Name, Last name, Middle name, Comment, Discount card number, Personal discount, E-mail, Sex |
| Address | Client address, city, house, postal code, block, metro, apartment/office number, entrance, address notes, region, country, building, street, floor |
| Source | Source, campaign, channel, keyword, campaign content |
| Custom fields | The client's custom fields configured in the CRM. They can differ between system users, so they are not listed separately in the documentation |
If a value is only needed for the current conversation and should not be saved in the client card, it is better to use the "State" source. But if the rule depends on stable CRM-profile data, use "Customer data".
The Schedules source
The "Schedules" source lets you build conditions by the current time. The system checks whether the current moment falls within the chosen schedule and, based on that, can open the needed step, skip an action, or direct the scenario down another branch.
Two types of schedules can be used in conditions:
| Schedule | What it checks | How to use |
|---|---|---|
| CRM working hours | Whether the current moment is inside the working hours configured in the CRM | For working-hours and non-working-hours rules: hand over to a manager only during working hours, promise a callback after hours, start different scenario branches |
| Agent's custom schedule | Whether the current moment is inside a separate schedule configured for the agent | For special time windows: a promotion, a team shift, a service's availability hours, a separate enquiry-handling schedule |
In a schedule condition, one of two states is usually checked: the current moment is inside the schedule or outside it. To check the time inside the schedule, true is specified in the expected value; to check the time outside the schedule, false. For example, one step can be opened only during the CRM's working hours, and another only outside them.
Operators
The operator determines how the system compares the value from the chosen source with the expected value.
| Operator | How it works | Example |
|---|---|---|
| Equal | The value matches the expected one. For text, case does not matter: Active and active are considered the same |
"Sender type" equals customer; "Agent is responsible" equals true |
| Not equal | The value does not match the expected one. For text, case also does not matter | "Responsible → Responsible type" not equal to user |
| Greater than | The numeric value is greater than the expected one | "Personal discount" greater than 10 |
| Greater than or equal | The numeric value is greater than or equal to the expected one | "Personal discount" greater than or equal to 10 |
| Less than | The numeric value is less than the expected one | "Floor" less than 5 |
| Less than or equal | The numeric value is less than or equal to the expected one | "Floor" less than or equal to 5 |
| Between | The numeric value is within the range, inclusive. Two bounds are specified in the condition: the minimum and the maximum value | "Personal discount" between 5 and 15 |
| Contains | The text contains the specified fragment. For a list, the presence of an element is checked. Case-sensitive | "Message text" contains STOP |
| Does not contain | The text does not contain the specified fragment. For a list, the absence of an element is checked. Case-sensitive | "Message text" does not contain stop |
| Starts with | The text starts with the specified value. Case-sensitive | "Message text" starts with call_ |
| Ends with | The text ends with the specified value. Case-sensitive | "Channel name" ends with support |
| Is empty | The value is missing or empty: not filled in, equal to an empty string or an empty list | "Sender phone" is empty |
| Is not empty | The value is present: a non-empty string, list, or other value | "E-mail" is not empty |
| Matches regular expression | The text matches the regular expression. If the expression is malformed, the condition will not be met | "Message text" matches ^call_\\w+ |
| Does not match regular expression | The text does not match the regular expression. If the expression is malformed, the condition will not be met | "Message text" does not match ^call_\\w+ |
Step conditions
Step conditions control whether a scenario step is available at the current moment. If the conditions are not met, the step does not take part in the scenario's work: the agent will not be able to choose it as the next step, a signal-associated step will not start, a transition to this step will not be created, and a reminder to it will not be scheduled.
Step conditions are worth using when a step's availability depends on checkable data: working hours, a signal value, client data, the scenario state, or the parameters of the current message. For example, a step can be shown only to VIP clients, an escalation branch opened only on a negative signal, a promotional scenario started only on the right dates, or a repeated greeting not created if it was already sent earlier.
Conditions do not replace the step instruction. The instruction explains to the agent when and why to use an available step. Conditions, however, limit the very availability of the step in advance: if the rule did not match, the step is simply not considered as a possible option.
The same condition mechanism works for different types of steps. So conditions can be used not only for steps the agent chooses itself, but also for steps triggered by a client message, a signal, a reminder, or a transition from another part of the scenario.
Conditional transitions via the Go to another step action
The Go to another step action sets the agent's next direction in the scenario: which step to move to after the current step runs. Such a transition does not start several branches in parallel at once. The scenario keeps a single active direction, so if the first transition in the current step successfully chose the next step, the other transitions in this same step are no longer applied.
Before setting a transition task, the system checks the target step: it must be active, and its conditions must be met. If the target step is currently unavailable, no transition task to it is created, and the current step's execution continues. Thanks to this, you can configure several transitions in a row: the system will try the first suitable option, and if its conditions did not match, it will move to the next.
This makes transitions between scenario steps flexible. You can lead the agent into certain parts of the scenario only when the needed conditions match: for example, open a separate branch for clients with a specific tag, lead into a promotional scenario only during certain hours of a specific day, or move to the sale only when the signal shows the client is ready to buy.
Conditional reminder targets
The Delayed step launch action creates a reminder that later returns the scenario to the chosen step. Before creating such a reminder, the system checks the target step the same way as with a transition via the Go to another step action: the step must be active, and its conditions must be met right now.
If the target step is unavailable, the reminder is not created. This is important: the conditions are checked not at the moment of the future reminder launch, but before it is set. So the target step's conditions can be used as a filter that decides whether the delayed launch needs to be scheduled at all.
This approach is handy when a reminder should appear only in a suitable context: during working hours, for a certain client segment, after the needed signal, or while the scenario state still holds a relevant flag. For example, you can avoid creating a follow-up reminder if the client has already bought the product, the dialog has been handed over to a manager, or the follow-up step is currently closed by conditions.
Signal dependencies and steps triggered by signals
Signals use the condition system in two places:
- Dependencies between signals control which signals are available to the agent for analysis.
- Steps triggered through a reaction to a signal use step conditions to decide when it should be started.
Dependencies between signals
Dependencies between signals are needed when one signal makes sense to check only after a specific value of another signal. This lets you build the analysis up gradually: first check broad characteristics, and open more precise ones only after the first signals get the needed values. This way the agent does not check everything at once but works only with the characteristics that make sense right now.
For example: first determine the client's general mood. If the mood is negative, open a signal with the reason for dissatisfaction. If the reason requires a separate reaction, an escalation step can be started next.
A dependency itself does not set a signal value. It only decides whether this signal will be available for analysis on the current turn. When the signal becomes available, its value is determined from the conversation: it may appear, change, stay the same, or clear if the context of the conversation changed.
Steps triggered by signals
The signal check is performed once per client turn, before the agent's usual reply. During this check, the agent can determine the values of the available signals. After that, the system checks the steps triggered through a reaction to a signal.
A step triggered by a signal fires when the signal values and the step's other conditions match. Such a step can have additional conditions: by schedule, client data, the scenario state, or the parameters of the current event. For example, an escalation step can be started only on a negative signal and only during working hours.
If a hidden step has already been started by the current signal value, it is not started again. If the signal was cleared and then got a suitable value again, the associated step can start once more.
Conditional actions inside a step
Conditional actions control how the actions inside an already-called step run. Usually, the step's actions run in order from top to bottom. Conditional actions let you change this order: run only part of the actions, skip several of the following actions, stop the step, or temporarily block its execution.
| Action | What it does |
|---|---|
Run next actions |
If the conditions are met, the following actions run as usual. If the conditions are not met, the system skips the specified number of the following actions |
Skip next actions |
If the conditions are met, the system skips the specified number of the following actions. If the conditions are not met, execution continues as usual |
Stop step execution |
If the conditions are met, the step finishes, and the remaining actions inside it do not run. The step is considered completed, and the agent can continue working with the scenario |
Block step execution |
If the conditions are met, the step stops with a message for the agent. The agent must fix the situation and call the step again with different data |
Such actions are needed for small forks inside a single step. For example, you can create a reminder or, conversely, clear old reminders depending on whether the agent is waiting for a reply from the client; distribute the dialog in different ways taking the schedule into account; perform certain actions only if the dialog is assigned to the agent; or block the step if, when calling it, the agent did not pass the required variable values.
Conditional actions are suitable for choosing behaviour inside the current step. If you need to choose the next major scenario branch, it is better to use the Go to another step action rather than assembling a long sequence of conditional actions.