An action that runs at the wrong moment is worse than no action at all. A scheduling action that fires when someone asks a simple question. A notification that goes out before the user has confirmed anything. Actions that feel random erode trust fast.

A user asks your agent a general question about your product. Halfway through the response, a calendar invite lands in their inbox for a meeting they never agreed to. They are confused, then annoyed. The scheduling action fired because the trigger was written too broadly - it matched any conversation that mentioned a meeting, not just ones where the user asked to book one.

Triggers are how you prevent that. They are the plain-language instructions that tell your agent exactly when an action should run - and equally importantly, when it should not. This article shows you how to write them so your actions feel natural instead of intrusive.

In this article, you'll learn:

• How trigger instructions work
• How to write effective trigger instructions
• How to control how often an Action runs
• How response handling affects what the user sees

How Triggers Work

Every Action you create has a Trigger - a plain-language description of when your agent should run it. Your agent reads every user message and decides, based on your trigger instructions, whether this is a moment to activate the Action.

This means you don't write code or set up complex rules. You write a sentence or two describing the situation, and your agent uses that to make the decision.

Example trigger instructions:

"Use when the user asks about booking a demo, scheduling a call, or checking calendar availability."

"Use when the user asks about their order status, shipping, or delivery timeline."

"Use when the user asks a question that isn't answered by the available sources or asks for the latest news."

The more specific and clear your trigger is, the more reliably your agent will know when to use it - and when not to.

Writing Effective Trigger Instructions

Be specific about intent, not just keywords.

A trigger based on keywords alone is fragile. A user might say "I need help with my subscription" - your trigger shouldn't require the word "subscription" to fire. Instead, describe the intent:

✅ "Use when the user wants to check, change, or cancel their subscription or billing details."

❌ "Use when the user says subscription."

Cover variations of the same request.

Users phrase things differently. Think about the different ways someone might express the same need and include them in your trigger:

✅ "Use when the user asks to speak with a human, requests a handoff, says they want to talk to someone, or expresses frustration with automated responses."

Set clear boundaries.

If an Action should only run in certain situations, say so explicitly:

✅ “Use only when the user is asking about a specific order and has provided their order number. Do not use for general shipping questions.”

Controlling How Often an Action Runs

By default, an Action can run unlimited times in a single conversation. If that's not appropriate - for example, if the Action sends an email or makes an API call that shouldn't happen repeatedly - you can set a Trigger Limitation.

The Trigger Limitation controls the maximum number of times an Action can run per chat session.

To set it:

1. Go to the Actions tab.
2. Open the Action you want to configure (or create a new one).
3. In the Settings section, find Trigger Limitation.
4. Set the maximum number of times it should run per session.

Choosing Which Channels an Action Runs On

Actions can run on Chat, Email, or both. You set this in the Available Channels setting when creating or editing an Action.

• Chat: The Action runs during live chat widget conversations.
• Email: The Action runs when your agent is handling email conversations.

Some Actions make sense on both channels. Others - like booking a meeting or looking up a live order status - may only make sense in chat where the user is present in real time.

Response Handling: What the User Sees

After an Action runs, your agent needs to communicate the result to the user. The Response Handling section lets you control how that happens.

Response Format

Choose how the result is presented:

• Text: The agent writes a natural-language response based on the Action's output. Best for most situations.
• Card: The result is displayed as a structured card - useful for presenting structured data like order details or meeting confirmations.
• Link: The result is shown as a clickable link.

Custom Response Instructions

Toggle this on if you want to give your agent specific instructions for how to interpret and present the Action's output.

Example: "Tell the user their booking is confirmed and include the date, time, and a calendar link. If the booking fails, apologize and suggest they try again or contact support."

If you leave Custom Response Instructions off, your agent will decide how to present the result on its own based on the data returned.

Best Practices

• Write trigger instructions in the same language your users use - not technical or internal terminology.
• Always set a Trigger Limitation on Actions that send emails, make bookings, or call paid APIs - you don't want these firing five times in one conversation.
• Use the Preview panel to test your triggers by sending messages that should and shouldn't activate the Action, and verify the agent responds correctly each time.
• If an Action is firing when it shouldn't, tighten the trigger instructions. If it's not firing when it should, broaden them.