Trigger Configuration
What It Is:
Trigger Configuration is the process of defining the event or condition that initiates a Workflow. This is the starting point for any Workflow. Triggers can be based on user actions (like sending a message), system events (such as a ticket being created), or specific conversation attributes.
Key Elements:
-
Trigger Types: Examples include “Customer sends their first message,” “Teammate changes the conversation state,” “Customer has been unresponsive,” or “Customer visits a page.”
-
Audience Rules: You can specify which Users, Leads, or Visitors the Workflow should apply to, using filters like user attributes, browser language, or capacity.
-
Channel Selection: Choose where the Workflow should trigger (Web, iOS, Android, WhatsApp, Facebook, etc.).
-
Scheduling: Set when the Workflow should be active (e.g., only during office hours).
-
Goal Setting: For some Triggers, you can define a goal to measure the Workflow’s impact (e.g., conversion to a paid plan).
How It’s Used:
Trigger Configuration is about deciding “when” and “for whom” a Workflow should start. For example, you might configure a Workflow to Trigger only for trial users who have been active in the last 14 days and are browsing your pricing page.
Conditional Logic
What It Is:
Conditional Logic refers to the Audience rules and Conditional branches within a Workflow that determine how the Workflow proceeds after it has been triggered. It’s the “decision-making” part of the workflow, allowing you to create different paths based on user behaviour, conversation attributes, or other data.
Key Elements:
-
Branches: Use branches to route users down different paths depending on conditions you set (e.g., user language, conversation topic, office hours).
-
Conditions: These are logical statements (e.g., “If browser language is French, show French Workflow”) that control which branch is followed.
-
Data Sources: Conditional logic can use person data, company data, message data, conversation data, or capacity.
-
AND/OR Logic: Combine multiple conditions for more complex branching (e.g., “Last seen < 14 days AND browser language is English”).
-
Automated Actions: Based on the Path taken, the Workflow can perform actions like sending messages, tagging conversations, assigning tickets, or integrating with external systems.
How It’s Used:
Conditional Logic is about deciding “what happens next” after a Workflow is triggered. For example, after a Workflow is triggered by a customer message, conditional logic can branch the flow based on whether the customer is a paying user or on a free trial, and then send different follow-up messages or assign the conversation to different teams.
Aspect | Trigger Configuration | Conditional Logic |
Purpose | Defines when and for whom a Workflow starts | Determines the Path and Actions within the workflow |
Scope | Entry point to the Workflow | Internal decision-making and branching |
Configuration | Set in the Workflow’s trigger settings | Set using branches inside Workflow |
Examples | “When customer sends first message” | “If user is on free trial, send offer” |
Audience Rules | Used to filter who can enter the Workflow | Used to branch paths after entry depending on match |
Scheduling | Controls when Workflow can be triggered | Can be used in branches for time-based logic |
How They Work Together
-
Trigger Configuration gets the right people into the Workflow at the right time.
-
Conditional Logic personalises and adapts the Workflow journey based on real-time data and user behaviour.
For example, you might configure a Workflow to trigger when a customer calls your support line (Trigger Configuration), and then use conditional logic to route the call based on office hours, customer type, or the number dialled (Conditional Logic).
Negative OR Rules
When using OR with negative rules (e.g., "City is not Dublin OR City is not London"), the rule matches if either condition is true. This means almost everyone will match including users in Dublin or London because no one can be in both cities at once.
Example: - User in Dublin: "City is not Dublin" = False, "City is not London" = True → Rule matches (because one is true) - User in London: "City is not Dublin" = True, "City is not London" = False → Rule matches
Result:
You end up including users in Dublin and London, which is not what you want.
How to Fix It
Use AND instead:
"City is not Dublin AND City is not London"
-
Now, only users who are in neither city will match.
-
Users in Dublin or London will be excluded as intended.
To exclude multiple values, use negative AND rules, not negative OR rules.
Best Practices & Limitations
-
Use Audience rules in triggers to ensure only relevant users enter the Workflow.
-
Use Conditional branches for nuanced, real-time decisions (e.g., office hours, user attributes).
-
Move time-based or complex rules into branches rather than trigger settings for more flexibility.
-
Be aware of limitations, such as only one customer-facing workflow running at a time per conversation, and the lack of channel-specific branching.
Summary
-
Trigger Configuration = “When and for whom does the workflow start?”
-
Conditional Logic = “What happens next, and how do we branch the journey?”
Both are essential for building robust, automated Workflows that respond intelligently to user behaviour, conversation context, and system events.