This technical documentation dives deeper into how the different available blocks work within the Bot. You will find information for each one along with a few tips to follow good practices and quickly build efficient scenarios.

Chatbot scenarios are created by inserting and configuring "blocks" inside of a no-code workflow builder. By connecting these blocks, you can setup a flow of actions, conditions, and events to deploy automations for your inbox conversations.

Table of Content

• Blocks available with the Bot plugin

‎ ‎ ‎ ‎ ‎ ‎ ‎ ● Event Blocks

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → New User Message

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Message Matches

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Button/Input Action

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation State Changed

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → URL Change Detected

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Awaiting Operator

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Email Updated

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Name Updated

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Phone Updated

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Custom Data Updated

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Segments Updated

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → New Crisp Event

‎ ‎ ‎ ‎ ‎ ‎ ● Action Blocks

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > Composition

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > Text

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > Button Picker

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > Field Input

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > File Attachment

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > Animation (GIF)

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > Carousel

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Send Message > Private Note

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Update User Name

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Update User Email

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Update User Phone

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Update Custom Data

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Set with Bot Memory

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Add Session Segment

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Submit Event

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Update User > Ask User Feedback

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Internal Actions > Update Chat State

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Internal Actions > Wait

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Internal Actions > Block User

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Internal Actions > Mention Operator

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Internal Actions > Assign Operator

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Internal Actions > Move to Inbox

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Internal Actions > Submit Web Hooks

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → AI Actions > Evaluate Intent

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → AI Actions > MagicReply

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → AI Actions > Search Helpdesk

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → AI Actions > Search Answers

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → AI Actions > Search Web Content

‎ ‎ ‎ ‎ ‎ ‎ ● Condition Blocks

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation is New

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Time Passed Since

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation Segments

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Contact Segments

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation Custom Data

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Contact Custom Data

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Current Page URL

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Location

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Language

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Current Hour

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Current Day

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Bot Memory has Data

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Email Matches

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Email is Set

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Phone is Set

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User Name is Set

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation State

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → User is Available

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Support is Available

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Contact is Verified

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation Channel

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation Inbox

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Conversation Subject Matches

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → HTTP Response Matches

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Message Intent Matches

‎ ‎ ‎ ‎ ‎ ‎ ● Exit Blocks

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Stop Scenario

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Run Scenario

● Block Options

● Concepts

Blocks available with the AI chatbot builder

When creating AI chatbot templates, you will encounter the following types of blocks:

• Event: an event that triggers progress in the scenario map, eg. message received
• Action: Performs an action, eg. send a message
• Condition: checks for a condition, eg. if user has an email set
• Exit: used to end the scenario; this block is not always required but is also useful for connecting to another scenario or stopping the current one.

The Entry Gate is simply your starting point for each scenario. This is where your scenario starts, from which you should connect your very first block.

Event Blocks

The Event Blocks are "listeners". They are used to detect when something occured, such as when the user has sent a message, when the state of a conversation changed, or if a button was clicked for instance.

When an Event block is reached, the scenario will pause itself until the event it is monitoring occurs.

✹ New User Message

Detects when a new message of any type been sent by the user

This Event block is able to detect any type of message (text message, images, files, voice message...).

It is very commonly used to start your scenarios (similarly to the User Message Matches) but also when requesting the user to ask a question, for instance before using a MagicReply AI Action block.

You can configure this block to select which messages origins (channels) it should detect: chat, email, whatsapp, telegram, etc... This is particularly convenient if you wish to have different branches for different channels.

✹ User Message Matches

Detects text messages sent by the user containing a specific patterns.

Unlike the New User Message block, this one only detects text messages but also allows you to only trigger for specific patterns or words contained in that message.

This is very commonly used to only start a scenario or branch when a particular keyword is included in the user's message.

To detect certain terms/keywords inside of a sentence (instead of an exact message match), you can use * wildcards around your term, such as *demo* to detect messages such as "I'd like a demo please".

By default it will detect messages from all origins if none are specified, but you can select the message origins (channels) it should detect: : chat, email, whatsapp, telegram, etc...

The Negate option allows you to exclude the specified terms instead. For instance for a pattern match of *demo*, if Negate is enabled, the block will detect all messages which don't contain the wod "demo".

✹ Button/Input Action

Detects when the user clicks a button or submits a field input.

This Event block is generally used right after a Button or Field Input action block.

A few possible configurations are available:

1. Message Action: Simply select Field Fill for a Field Input
2. Match: The value you wish to detect : generally "Any" for a Field Input, and the value of the button for a Button Picker
3. Memorize value: If the value submitted should be memorized by the Bot (generally yes for a Field Input)
4. The "key" the value should be memorized in. For instance if you ask the user for the name of their company, you can could memorize it in a company-name key

✹ Conversation State Changed

Detect when the state of a conversation has changed.

You can select which conversation state the block should detect, among:

• Pending: a conversation which contains unread messages
• Unresolved: when a conversation is still ongoing, but messages have been read
• Resolved: the conversation has been marked as resolved (closed)

✹ Awaiting Operator

Triggers if the user's message hasn't been read any any agent after 2 minutes.

✹ User Email Updated

Triggers when user's email address is either set or changed in the conversation.

Can be for instance be used to pause the scenario while updating the user's email address through the REST API.

✹ User Phone Updated

Triggers when the user's phone number is either set or changed in the conversation.

Can be for instance be used to pause the scenario while updating the user's phone number through the REST API.

✹ User Name Updated

Triggers when the user's nickname is either set or changed in the conversation.

Can be for instance be used to pause the scenario while updating the user's nickname through the REST API.

✹ Custom Data Updated

Triggers when a conversation custom data is either set or changed in the conversation.

You can detect if a custom data was updated to a specific value, but also to "any" by using the wildcard match *.

This is often used after sending a Webhook through the Bot, and resuming the flow after updating a custom data to to signal the Bot your back-end operations have completed.

✹ Segments Updated

Triggers when a conversation segment is either set or changed in the conversation.

Can be for instance be used to pause the scenario while updating the conversation segments through the REST API.

✹ URL Change Detected

Detect the moment a user navigates to a specific URL of your website.

When specifying a URL to check, you can use wildcards in order order to check for any path or sub-path. If you specify several urls, this block will trigger once the user navigates to any of the specified URLs

✹ New Crisp Event

Detect when a specific Crisp event has been pushed with the SDK (Javascript, iOS, Android, React Native)

This particular Event block is mainly used to start a Bot scenario programmatically, before the user has sent a message for instance.

Because Crisp events are then attached to the user's profile, it requires the user to have an email address set in their session (for the event to be attached to that profile)

Don't hesitate visiting this dedicated guide to learn more about it. You can also check our JS SDK documentation to learn how to push events.

Action Blocks

The Action Blocks, as their name suggest, allow you to perform an action during the execution of the scenario. They can be used to send messages to a user, resolve a conversation, memorize information, and much more.

They are categorized into 4 groups:

• Send Message: allows you to display an operator-sent message in the conversation (text message, image, button picker, field input...)
• Update User: used to add/update information about the user in the current conversation
• Internal Actions: used when you would like to affect a conversation's state and perform actions that are not directly visible to your users in the conversation
• AI Actions: leverages AI to perform actions (evaluate intent, generate AI responses, and more)

✹ [Send Message] Text

Used to send a regular text reply to the user.

Just like any message sent in the chatbox, you can format it with markdown in order to customize it further.

You can also insert replacement tags, to output information you've collected during that scenario, custom data, or access global variables such as the user's name or email for instance. We have a dedicated section about variables and replacement tags.

And finally, you may also translate it in multiple locales, so that Crisp outputs the message that matches the user's language 🇬🇧

✹ [Send Message] Composition

Displays a composition animation for the specified duration.

This block effectively pauses the execution of your scenario while a ... animation is displayed on the user's end. You can specify the duration the animation should last, before the Bot moves to the next block.

✹ [Send Message] Button Picker

Displays interactive button pickers to the user.

This block can be user to offer choices to your users, to continue to a specific branch of your scenario.

The option Require a selection to continue will prevent the user from sending new messages until they've completed that step (until they've selected a choice).

These blocks can also be translated it in multiple locales, so that Crisp outputs the message that matches the user's language 🇩🇰

By default, buttons will simply allow the user to continue the scenario on your specific branch, but you can also use them to open links by hitting the ⚙️ icon next to each of your buttons.

You can then specify your URL and choose how the link should open:

• External link to open the url in a new tab of the browser
• Embedded link in order to open the url directly in the chatbox (especially useful to easily share a calendar, form, articles...)

You can consult this article to find more information about sharing links by using button picker.

When using Button Picker action blocks to "send" them to the user, you must then always use Button/Input event blocks to detect the user's selection. This block essentially pauses the scenario until the user completed that step to detect it, and allows you to start your different branches.

Those can easily be added into the scenario by hovering the button in the editor and hitting the ⚡️ icon which appears.

More examples of Button Picker usages are available in this dedicated guide as well.

✹ [Send Message] Field Input

Displays a field input to your users.

This block is used to collect information from your users which can then be memorised by the Bot (such as an email address, name, tracking number, or any other information).

The option Require a selection to continue will prevent the user from sending new messages until they've submitted that information.

These blocks can also be translated it in multiple locales, so that Crisp outputs the message that matches the user's language 🇩🇰

When using Field Input action blocks to "send" them to the user, you must then always use Button/Input event blocks to detect the user's submission. This block essentially pauses the scenario until the user completed that step to detect it, and allows you to start your different branches.

Those can easily be added into the scenario by hovering the button in the editor and hitting the ⚡️ icon which appears.

More examples of Field Input usages are available in this dedicated guide as well.

✹ [Send Message] File Attachment

Shares a file in the conversation.

This block shares a file which is hosted externally, allowing the user to download it. This can be used for videos, CSV, PDFs, and many more supported file extensions.

When using it, you must specify:

• The file's name that will be displayed in the message (e.g. Orange_cat.png)
• The file's url (e.g. https://acme.com/assets/picture_of_orange_cat.png)
• The file's mime-type depending on the format of your file (e.g. image/png)

✹ [Send Message] Animation (GIF)

Insert a GIF animation in the conversation.

This allows you to share a GIF with your users, by specifying its url.

✹ [Send Message] Carousel

Displays a Carousel of items/products.

Each item can be customized with a title, image, or description, and allows you to add buttons which will open the URL you specify there once clicked by a user.

Some usage examples are available in this article.

✹ [Send Message] Private Note

This Action block sends a private note message in the conversation.

Notes are not visible by users, only your operators will be able to view it in the conversation.

✹ [Update User] Update User Name

Updates the user's nickname in the conversation.

This often used after collecting the user's nickname through a Field Input.

The flow generally looks like this:

1. Action: Field Input => to display a field input and ask the user for the information
2. Event: Button/Input => with Field Fill action and the Any match, and enabling the Memorize to save the value submitted by the user
3. Action: Update User Name => To select the value saved in step 2 and update the user's nickname

✹ [Update User] Update User Email

Updates the user's email address in the conversation.

This often used after collecting the user's email address through a Field Input.

The flow generally looks like this:

1. Action: Field Input => to display a field input and ask the user for the information
2. Event: Button/Input => with Field Fill action and the Any match, and enabling the Memorize to save the value submitted by the user
3. Action: Update User Name => To select the value saved in step 2 and update the user's email

✹ [Update User] Update User Phone

Updates the user's phone number in the conversation.

This often used after collecting the user's phone number through a Field Input.

The flow generally looks like this:

1. Action: Field Input => to display a field input and ask the user for the information
2. Event: Button/Input => with Field Fill action and the Any match, and enabling the Memorize to save the value submitted by the user
3. Action: Update User Name => To select the value saved in step 2 and update the user's phone number

✹ [Update User] Update Custom Data

Adds/Updates a custom data in the conversation with a static value

The Custom Data set from this block is "static", meaning you cannot use variables memorized during the scenario.

It used if the custom data you wish to set doesn't depend on a value they submitted through a Field Input. For instance if you wish to always add a generic user_role: customer after they've clicked a button asking them to select their role.

✹ [Update User] Set with Bot Memory

Adds/Updates a custom data in the conversation, with a memorized (dynamic) value.

This often used after collecting the user's nickname through a Field Input.

The flow generally looks like this:

1. Action: Field Input => to display a field input and ask the user for the information
2. Event: Button/Input => with Field Fill action and the Any match, and enabling the Memorize to save the value submitted by the user
3. Action: Update User Name => To select the value saved in step 2 and update the user's nickname

✹ [Update User] Add Session Segment

Adds a segment to the conversation.

Segments (Tags) are used to categorize the conversation. They are often used after the user has made a specific choice (following button pickers for instance), but can be very helpful in many situations.

✹ [Update User] Submit Event

Pushes an event in the user's profile.

Events are mainly used to send Automated Campaigns to your users. They are also visible from the conversation/profile 30 days after being pushed.

✹ [Update User] Ask User Feedback

Sends a Feedback Request in the user's chatbox.

The feedback will appear in their chatbox, allowing them to rate the conversation and leave a comment.

Feedbacks left by users are visible from the Analytics.

This block is more commonly used in the context of AI scenarios, for instance after asking users if the response generated by MagicReply helped them resolve their issue.

✹ [Internal Actions] Update Chat State

This Action block changes the state of the conversation among one of the three states:

• Pending: a conversation which contains unread messages
• Unresolved: when a conversation is still on-going, but messages have been read
• Resolved: the conversation has been marked as resolved (closed)

✹ [Internal Actions] Wait

Temporarily pause the execution of the scenario for the duration specified.

The maximum time is 30 seconds, though it is technically possible to chain multiple ones in a row to extend it.

Note that messages sent by operator during a Wait block will not interrupt the scenario, meaning that it will execute the next block even is an agent intervenes during that Wait block.

✹ [Internal Actions] Block User

Blocks the current user.

When used, this will always block both:

• Their email address: you will not longer receive emails from their address, if one was set
• Their IP address

We recommend using the Triage feature when looking to mark certain messages as spam based on their content, but this block can also be used as a substitute if you wish to block users sending certain explicit messages (after a User Message Matches for instance).

✹ [Internal Actions] Mention Operator

Mention an operator in the conversation.

The mention will appear as a private note, and the operator will be notified according to their notification settings.

You can select multiple agents to be mentioned (this will mention all of them regardless if they are online or not).

✹ [Internal Actions] Assign Operator

Assign/Unassign an agent to the conversation.

Only one agent can be assigned with this block.

✹ [Internal Actions] Move to Inbox

Moves a conversation to a specific inbox.

Allows you to move a conversation to a specific sub-inbox or the main inbox. You can read more about Sub-inboxes in this article.

✹ [Internal Actions] Submit Web Hooks

This Action block allows you to submit Webhooks from your scenario to your server (or no-code tools such as Zapier, N8N, Make...)

The Webhook block can be configured with 3 properties, which will all be included in the request payload:

• Name: The name of the event, which allows you to distinguish which webhook block has triggered if you have several (in the same scenario or different ones)
• Memorized Keys: Values memorized during the execution of a scenario (eg: the email address of a user you collected with an input field in the same scenario)
• Static Data: Arbitraries key/value pair, specific to that block (eg: is_member: true)

The payload schemas that your server will receive can be consulted here in our Developer Hub.

To register the webhook, you need to subscribe to the plugin:event event. You have 2 options available, depending on your preferences and setup:

• Plugin Webhooks: You can register a webhook endpoint inside of your plugin settings, from your marketplace account
• Website Webhooks: In app.crisp.chat, by heading to Settings > Website Settings > Advanced Configuration > Webhooks

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Name: The name of your webhook (it doesn't have to match the "name" of your Webhook block, this is purely informative)

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Endpoint: The URL of your webhook

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ → Event: The Events this endpoint is subscribed to, which should include plugin:event (last one in that list)

✹ [AI Actions] Evaluate Intent

Allows you to detect customers' intent based out of a custom prompt you define.

This AI feature is not aimed at "generating" a response, but instead at "evaluating" the user's intention or the topic of their request.

It for instance allows you to detect if the user:

• requests information about an order (tracking, shipping...)
• has a question related to billing
• is looking to contact a human agent
• is getting frustrated or wants to cancel his account
• and many more

This block evaluates the intent from the user's messages specifically. This implies that it is generally placed at some point after a New User Message event block.

The evaluation is done in 2 steps:

1. Through this Action block Evaluate Intent where you can define the intents you wish to detect. You can define up to 5 and give a prompt to the AI to describe which messages should be detected as such
2. By placing Message Intent Matches condition blocks to route the Bot flow depending on which intent was matched

Step 1 is the action of evaluating the intention, and Step 2 is assessing which intent was matched (if any) to take the proper branch.

✹ [AI Actions] MagicReply

This Action block allows you to suggest articles relevant to the query of your user

This special block leverages AI to suggest Helpdesk articles relevant to the last messages sent by the user. The AI is able to parse the content of the last messages sent, identify the request, and offer the user to visit articles relevant to their question.

You can customize the message attached, but also specify the locale of the articles which should be suggested.

When adding this block to your flow, you can also add a second Action block next to it (by adding a new child from its parent block). This secondary block will be executed if the AI does not find any article pertinent enough to be shared with the user.

A dedicated guide on this feature is available here

✹ [AI Actions] Search Helpdesk

This AI feature allows the Bot to search through your Knowledge Base articles to find resources which can answer the user's question.

By default, it will suggest up to 2 articles matching the user's question. You can also specify a message that will be inserted in front of the suggestion, such as "Here are a few articles which might help:"

You can also translate this block in multiple languages, and select which locales of your Knowledge Base the AI should search.

You can read more about AI resources training in this dedicated article 📚

✹ [AI Actions] Search Webpages

This AI feature allows the Bot to search through your Web content to find resources which can answer the user's question.

By default, it will suggest up to 2 web pages matching the user's question. You can also specify a message that will be inserted in front of the suggestion, such as "Here are a few pages which might help:"

You can read more about AI resources training in this dedicated article 📚

✹ [AI Actions] Search Answer

This AI feature allows the Bot to search through your Question/Answer snippets to find resources which can answer the user's question.

You can also specify a message that will be inserted in front of the suggestion, such as "Here is what we found regarding your question:"

You can read more about AI resources training in this dedicated article 📚

Condition Blocks

Condition Blocks are used to verify if a specific condition is met before continuing with your flow, but also to split them into different branches.

Each of these block accepts a "is" or "is not" parameter, allowing you to check the opposite as well.

For instance, after your initial "User Message Matches" Event block, you can split your scenario into 2 branches to check on one hand if the conversation is new ("is)" in order to ask the user for more information automatically, and on the other if it is not a new conversation ("is not") to greet the user a welcome back message.

✹ Conversation is New

Check if the conversation is new, meaning that there was no previous message history.

A conversation is new if it doesn't not contain any operator message (including human agent messages, but also Bot, AI or operator messages sent from the REST API).

This block essentially checks if the user had not received any "reply" yet. If the conversation history contains any operator message, the conversation will no longer be considered as new, even if those are older.

This block is often used right after the first "New User Message" Event block, when you would like a scenario to trigger only the first time the user contacts you.

✹ Time Passed Since

Check if the last exchange occurred more or less than the specified amount of time.

This block is almost exclusively used at the beginning of a scenario, shortly after your New User Message or User Message Matches block.

It allows you to compare the date of the last message (N) sent by the user with the previous one exchanged in this conversation (N-1), to check how long it has been since that message.

This will take any actual messages (other than events, notes or reminders) that been previously exchanged in account, whether it was sent by an operator or a user.

In the example below, it would check the delta between the 2 messages highlighted:

__As an example, if our scenario is configured to check for either: __

• Conversation is New (no previous operator messages exchanged)
• Time Passed Since greater than 3 days

Then, our Bot scenario would not have started when the user reached out in the above conversation, as the delta of that 2 messages (July 8th at 5:15 PM - July 6th at 4:30 PM) would be 2 days and 45 minutes.

✹ Conversation Segments

Checks if specific segments are set in the conversation.

If you specify multiple segments, they will be treated as an OR condition, meaning that the Bot will check if at least one of them is present.

Note that this block only checks Conversation Segments. To check Contact Segments instead, you can refer to this section.

✹ Contact Segments

Checks if specific segments are set in the conversation.

If you specify multiple segments, they will be treated as an OR condition, meaning that the Bot will check if at least one of them is present.

Note that this block only checks Contact Segments. To check Conversation Segments instead, you can refer to this section.

✹ Conversation Custom Data

Checks if a specific custom data exists (and optionally their value) in the conversation.

If you specify multiple custom data key/pair, they will be treated as an OR condition, meaning that the Bot will check if at least one of them is present.

If you want to check if a specific custom has one of multiple possible values, you would need to create an additional branch with a dedicated condition block.

Note that this block only checks Conversation Custom Data. To check Contact Custom Data instead, you can refer to this section.

✹ Contact Custom Data

Checks if a specific custom data exists (and optionally their value) in the contact's profile.

If you specify multiple custom data key/pair, they will be treated as an OR condition, meaning that the Bot will check if at least one of them is present.

If you want to check if a specific custom has one of multiple possible values, you would need to create an additional branch with a dedicated condition block

Note that this block only checks Contact Custom Data. To check Conversation Custom Data instead, you can refer to this section.

✹ Current Page URL

Checks if the page the user is currently on matches the ones you've specified.

When specifying a URL to check, you can use wildcards in order order to check for any path or sub-path.

Single wildcards * inside of a URL are used to detect any specific sub-folder. For instance, to detect both https://acme.com/fr/account and https://acme.com/en/account

You can use a Match value of https://acme.com/*/account

Double wildcards ** inside of a URL are used if you would like to match not only a specific sub-folder, by and of the path contained in these ones as well.

For instance, to match both https://acme.com/fr/dashboard/index.html or https://acme.com/fr/helpdesk/getting-started/how-to-install

You can use a Match value of https://acme.com/fr/**

✹ User Location

Checks the user's geographical location (country), based on their IP address.

If you choose to specify several, the Bot will check if the user is from any of the specified countries.

✹ User Language

Checks the user's main language.

If you choose to specify several, the Bot will check if the user's language matches any of the specified ones.

The user's language is defined differently depending on the conversation channel's specificities.

A few examples:

• Chat: detected based on the user's browser language preferences
• Whatsapp: detected based on the number prefix (+33 for French users for instance)
• Instagram: communicated by Meta based on the user's account preferences
• Email: detected by using an n-gram algorithm
• etc

✹ Current Hour

Checks if the current time (based on the selected timezone) matches the time range specified.

As an example, if you would like to check if the user is contacting you out of business hours, you could proceed with either one of the following way:

• checking if the time is between 18:00 and 09:00
• checking if the time is not between 09:00 and 18:00

✹ Current Day

Checks if the current day (based on the selected timezone) matches the days specified.

As an example, to check if the user is contacting you during the week-end, you could either:

• check if the day is Saturday + Sunday
• check if the day is not Monday + Tuesday + Wednesday + Thursday + Friday

✹ Bot Memory has Data

Checks if a specific data (or its value) has been memorized by the Bot during this scenario

Memorized data are specifically values that have been memorized inside of a Button/Input Event block.

This block allows you to check:

• if the value is set (which will usually be the case if you used an event block to detect the submission) by checking the wildcard "any" value with *
• if the value matches something more specific, for instance by using Pattern Matches

✹ User Email is Matching

Checks if the user's email address matches a specific one.

This is often used to check if an email address (or parts of it) matches a specific one. It is for instance commonly used to then add segments to particular contacts, route them to a sub-inbox, or any action you wish.

You can also use Pattern Matches here to detect certain domains.

A few examples:

• *@acme.com to detect if the user's email address ends with @acme.com
• john.doe@gmail.com to check if the user's email address is exactly john.doe@gmail.com

✹ User Email is Set

Checks whether or not the user's email address is set in the conversation.

A good practice is to use those condition blocks before asking the user for their email address, by creating 2 branches:

• one for IS set
• one for IS NOT set

In order to move to the next step directly if the user's email is already present in the conversation, to avoid redundant questions.

✹ User Phone is Set

Checks whether or not the user's phone number is set in the conversation.

A good practice is to use those condition blocks before asking the user for their phone number, by creating 2 branches:

• one for IS set
• one for IS NOT set

In order to move to the next step directly if the user's phone is already present in the conversation, to avoid redundant questions.

✹ User Name is Set

Checks whether or not the user's nickname is set in the conversation.

A good practice is to use those condition blocks before asking the user for their name, by creating 2 branches:

• one for IS set
• one for IS NOT set

In order to move to the next step directly if the user's name is already present in the conversation, to avoid redundant questions.

Note: a default nickname such as Visitor476 will not be considered an actual name.

✹ Conversation State

Check the current state of a conversation.

This block can check if the current conversation state matches one of the following:

• Pending: a conversation which contains unread messages
• Unresolved: when a conversation is still on-going, but messages have been read
• Resolved: the conversation has been marked as resolved (closed)

To check if a conversation state is either "A" or "B", you can select an additional condition, or simply check if the conversation state is not "C"

✹ User is Available

Checks if the user is online (still active on your website).

A user is considered online if they are still present on your website, on a page where the chatbox is present.

✹ Support is Available

Checks if your support is still online.

As long as at least one of your agents appear online, the support will be considered as "available".

However, if all of your agents are offline (or invisible), the support will then be considered as "unavailable".

This condition block is commonly used for Out-of-Office responders, alongside Current Day and Current Hour blocks.

✹ Contact is Verified

Checks if the user's identity has been verified.

This block is part of the Identity Verification functionality of our Javascript SDK.

It allows you to check if the user's email address has been verified through one of the available methods (JS SDK, Email DKIM, REST API...).

This is often handy when sending webhooks or fetching details about a user from your database, for additional security.

✹ Conversation Channel

Checks the channel of the conversation.

It allows you to condition or split your flow in several branches depending on the channel the user is contacting you from.

You can select/exclude any of the natively supported channel (but also several) such as Whatsapp, Instagram, Email, Chat, etc

✹ Conversation Inbox

Checks the inbox that conversation is currently located in.

This block is often used to check inside of which sub-inbox the conversation is currently located in (for instance if you then wish to move it out, segment it, or perform different kind of actions).

✹ HTTP Response Match

Sends a request to your server and checks if the response matches what you expect.

It sends either:

• a GET request if you are checking for a body content
• a HEAD request if you not checking for any body content (and just a response status code)

When checking for a body content, make sure that the pattern you are detecting are indeed included inside of the response body (whether it is JSON, HTML, XML, etc).

You can also append url or query parameters to the request url by using Replacement Tags.

For instance, to pass the user's email as a query parameter, you could use: https://acme.com/endpoint?user_email={{ email }}

✹ Conversation Subject Matches

Checks if the subject of the conversation matches a specific one.

This condition block is most commonly used in Email conversations, to check for patterns inside of a subject.

It is often very handy to detect certain types of emails: PO Orders, Notifications, Automated emails, etc, to perform actions such as moving them to a sub-inbox or segmenting them.

Care for a few examples?

• To detect a subject such as "Your crispy order #FR00409 is on its way", you would likely use a pattern match of *crispy order*
• To detect a subject containing "An invoice has been generated", a simple *invoice* pattern detection might do the trick

✹ Message Intent Matches

Checks if the intent evaluated by the "Evaluate Intent" AI Action block matches the specified ones.

This condition block must always be used after the Action block Evaluate Intent, which uses AI to evaluate the intention of the user's message (to detect the topic of their request, their tone, etc) and route them to specific branches of your scenario.

It is not necessary to position it right after (you can check it later down your flow) but it must have been evaluated before you can use that condition block.

You can configure it to either detect if it matches the specified intent, or if it doesn't match them.

Exit Blocks

Exit blocks terminate the execution of the current scenario.

They are optional, and whether you should them is contextual. We'll review how they work to help you have a better understanding of them.

✹ Stop Scenario

Prevents your Bot scenarios (or specific ones only) from triggering again in this conversation for the next 24 hours.

It is generally used at the end of scenario (as the last block of your branches). This block essentially instructs the Bot "Do not start scenarios again in this conversation for the next 24 hours".

You can configure this block to only prevent a specific scenario from starting again within 24 hours (by default, it will prevent them all).

This block is completely optional and situational, your branches don't necessarily need to end with one, depending on the behaviour you're looking for.

By default, a scenario can start again once competed, if the user sends a new message. There are however other ways to adjust that, such as:

• Conversation is New => to only trigger in a conversation where there was no agent/bot response yet
• Time Passed Since => to only trigger if the last exchange occurred more or less than a specified time

✹ Run Scenario

Allows you to start another scenario.

This block can be used to trigger another scenario from current one.

It is a good way to reuse some of your other scenarios if they have common steps, but also to divide your flow into smaller scenarios to make them more easily maintainable.

Concepts

Pattern Matches

Several blocks allow you to match or detect certain patterns (or keywords, terms). Namely blocks such as User Message Matches, User Email is Matching, or Current Page URL (for a few examples).

By default, when you specify a term in those blocks' configuration, the Bot will look for an exact match.

For instance, if you simply match hello inside of a User Message Match block, it will only detect messages strictly containing "hello". Not "hello, how are you", not "Hello", only "hello".

To match specific patterns instead, we use the wildcard symbol * or its double wildcard variant **.

→ Single wildcards * before or after a pattern will detect a word inside of a sentence, even if there are other words either before or after (depending on where you placed it).

As an example, in order to capture the word "help" inside of the message "Hello, I need help from your support team" you will need use a Match value of *help*.

Single wildcards also detect capitalization and punctuation next to the term you're detecting, no worries! *hello* will be just able to detect "hello there", "hello!" or "Hello, i need help".

→ Double Wildcards ** are used exclusively to detect a pattern inside of a word.

So instead of * which detects a word inside of a sentence, ** detects patterns inside of that word. Let's clarify with an example:

Using a Match of **count** will detect "count" but also "account", "counting", "accounting", etc.

Using a Match of *ran** will detect sentences such as "I ran the full 14 miles" or "he was out of range, but not "I ate an orange" (because we only have a single wildcard before ran)

They have a similar but slightly different purpose inside of an URL:

→ Single wildcards * inside of a URL are used to detect any single sub-directory.

For instance, to detect both https://acme.com/fr/account and https://acme.com/en/account, you can use:

https://acme.com/*/account

→ Double wildcards ** inside of a URL are used if you would like to match not only a specific sub-folder, by and of the path contained in these ones as well.

For instance, to match both https://acme.com/fr/dashboard/index.html or https://acme.com/fr/helpdesk/getting-started/how-to-install, you can use:

https://acme.com/fr/**

So to match a detect a full domain such as microsoft.com, you would generally specify 2 URLs in your block:

• https://microsoft.com => for the home page
• https://microsoft.com/** => for all other sub-pages

Translating Scenarios in other languages

When using AI (with the MagicReply block), the AI will automatically send its response in the same language as the user's message. However, this is not the case for "static" messages (the regular ones you configure inside of other action blocks). You have to provide a translation for those, which the Bot will use accordingly.

Inside of Action blocks sending messages into the conversation, you have the ability to directly provide a translation for that message/options.

In the block's configuration, you can add "languages" to provide a specific messages that will be displayed to those users.

You can translate messages for all the languages you wish to support, and the Bot will automatically send the adequate one when the user triggers your scenario.

For instance, if you specified translations for French, Italian and Spanish, and your "Default" message in English: a Turkish user (for which you didn't set any specific translation) will see the default English message displayed.

Crisp detects the language of the user differently depending on the conversation channels. For instance "Chat" conversations rely on the user's browser preferences, "Instagram" uses the Meta account preferences, etc...

Proxy Blocks

As your scenarios grow, you might reuse certain parts of a scenario or redirect the user to a previous step. You might end up in situations where you have wires crossing your scenario in all directions, making it harder to read and navigate... There is a solution to that

When selecting a block, you will notice a ︙ menu at the top-right, from where you can hit the Copy as Proxy option, which you can then paste somewhere in your flow and link like any other block.

Once the user reaches that block during the scenario's execution, they will be teleported to that step, as if you had directly wired it. This is essentially a "vortex" to cleanly lead the user to another part of your scenario without dragging wires back and forth.

Variables and Replacement Tags

In your scenarios, you can use replacement tags to inject dynamic values. This is for instance helpful to insert the user's name in a message or to share an order tracking link stored in custom data.

They can be inserted in a message or URL by using curly braces, such as {{ email }} if the user has an email address set in the conversation, or {{ data.company_size }} if a company_size data custom data is set either on their conversation or profile.

• Global variables: They can be used globally in your bot scenarios as long as the value is set in the conversation

‎ ‎ ‎ → {{ name.full }} {{ name.last }} {{ name.first }}

‎ ‎ ‎ → {{ email }}

‎ ‎ ‎ → {{ phone }}

‎ ‎ ‎ → {{ city }}

‎ ‎ ‎ → {{ country }}

• Local variables (memorized values): Those are variables memorized by the Bot inside of Button/Input Event blocks

‎ ‎ ‎ → E.g. If you asked a user website url and memorized it as website_url you would use it with {{ website_url }} inside of a message.

• Custom data: Any custom data (profile or conversation) can be accessed through the data prefix in a replacement tag, such as {{ data.key_name }}

‎ ‎ ‎ → E.g. If the user user profile or conversation had a custom data tracking_order set, you can access it by using {{ data.tracking_order }}

Scenario and Branch Priority

You might notice numbers on each of your scenarios and branches as soon as you start having multiple. Those determine their Priority (aka the order in which the Bot will evaluate them).

When you receive a new message, the Bot evaluates your scenarios one by one until it finds an Action block to execute.

If the first scenario starts with a "User Message Matches" which doesn't match the user message, or if the conditions do not allow it (eg. time of the day, conversation is new, etc...), the Bot will check the next scenario, and so forth, until it is able to execute an Action block.

If it finds an Action block which can be executed (so if the conditions of that scenario allowed it), this scenario starts and the Bot will not execute the other ones. This is why the order in which you position scenarios matter. As these determine in which sequence the Bot will check them.

The same is true once inside of a scenario. If your scenario contains multiple branches, you will see a little priority number appear on the wire which determined the order in which the Bot will evaluated them.

Here as well, the Bot will take the first branch it "can" take. So if the first branch contains a simple action block (such as "Mention Agent"), the Bot will always take it and not check the other ones (as it can always perform a "mention" without issues).

However if you have condition blocks below each of these branches, which may or may not be true depending on the context of the flow, then the Bot will evaluate them one by one and take the first branch for which the conditions passed.

Frequently Asked Questions

What better way to end a guide than a FAQ section? If you still have questions, perhaps you'll find the answer you're looking for here!

You'll find some extra information to dive even deeper in the Bot and have the opportunity to review some of the most common questions

Don't hesitate visiting our Getting Started with the Crisp chatbot guide for extra tips!

If your question does not figure here, share it with us directly by chat, we'll be available!

Why are my users unable to type in the chatbox so suddenly?

You may have triggered a scenario with "Required" fields or buttons. This option, available on both of these blocks, will prevent the user from sending message until the previous button or field has been completed.

In such cases, your users will see a yellow banner letting them know that a step is required in order to continue the conversation.

How can I track how often scenarios or specific branches have been followed by my users?

You can do achieve that by using the "Add Session Segment" Action block at key moments of your scenario. For instance, when a specific URL is detected or when you users click on a button!

You will then be able to track the frequency of apparition of these segments in the Analytic tools, allowing you to monitor the paths taken by your users.

Can I use a webhook to send a request to the Bot and continue the flow?

Webhooks allow you to communicate with your server in one-way only.

You can use the Bot to send data from your bot scenario to your server, but if you'd like to do an action or send a message containing information fetched from your database you will need to use the API instead.

Don't hesitate checking our REST API references to get started in that direction.

How can I create loops, to take my users to a previous step?

You can simply connect your block to another one previously used one with a wire, and this without any issue. The block you then link towards will be executed even if it was already used in the past.

This is for instance helpful if you wish to share a button picker to offer your users the option to go back to a previous step. Once the event block of your button added, you can then connect it to the step you wish to take them back to.

However it can be cumbersome to have wires around going back across your scenarios, rendering it quite difficult to manage. To resolve that, you can also use Proxy blocks.

You can select the block you wish to go back to and from to see an option appear: "Copy as a Proxy". You can then paste this block in your flow (in our earlier example, after the event block of our button) and when this block is executed it will take them back to that block automatically, just as if you had connected it, but without the extra wires, to make it more readable.This technical documentation dives deeper into how the different available blocks work within the Bot. You will find information for each one along with a few tips to follow good practices and quickly build efficient scenarios.

Updated on: 12/08/2025