Home Automations, SLA and service rules

Automations, SLA and service rules

Automations, auto-resolution, follow-up, SLA and queue distribution.
Manuela Farias
By Fernanda Costa and 9 others
• 21 articles

How the Events Triggering Automations in CloudChat Work

CloudChat automations are triggered based on events. To ensure that rules work correctly, it is essential to understand the sequence of these events in a conversation's lifecycle. Responsibility of Each Event 1. Conversation Created Always the first event. Triggered as soon as the conversation (ticket) is created. Best practice: use this event only to assign initial values (e.g., inbox, priority, agent, or tags). 2. Message Created Happens whenever a new message enters the conversation. Occurs during conversation creation (e.g., when the customer sends an initial message to open support). Best practice: use for reactive actions, such as applying tags based on message content or triggering webhooks. 3. Conversation Updated Triggered when there are changes to an existing conversation: status change, agent assignment, team inclusion, priority update, etc. Best practice: use when needing to monitor flow changes, not just creation. 4. Conversation Opened Occurs when a previously resolved, pending, or delayed conversation is reopened by an agent. Best practice: use to resume automated flows (e.g., reassign to the same team that previously resolved it). Typical Execution Flow - Customer opens support by sending a message → Conversation Created and Message Created run in parallel - Any field change (status change, agent assignment, team inclusion, priority update, etc.) → Conversation Updated - Agent resolves the conversation → Conversation Updated (status = resolved) - Agent reopens the ticket manually → Conversation Opened and Conversation Updated run in parallel Common Error Cases 1. Concurrency Between Automations - Different events occurring under the same condition Error: two automations modifying the same field (e.g., agent or priority) on the same event. Solution: always validate additional conditions so that only one rule applies. Example: 2. Overwriting elements that are referenced by an action Error: setting actions that replace already filled values (e.g., custom fields or agent). Solution: automations should never leave fields empty or delete information without checking if they are used in other automations. 3. Incorrect use of “equals FALSE” conditions Can cause unexpected mass triggers. Solution: prefer using “not TRUE”. 4. Excessive actions in a single automation Can cause loops or chain reactions that are hard to trace. Solution: split large automations into smaller, independent rules. 5. Webhook not triggering If success/failure icon does not appear → the automation did not run. Common cause: poorly defined conditions or conflicts with other automations blocking execution. By following these best practices, you ensure that your CloudChat automations work predictably, efficiently, and conflict-free. Before publishing any automation, always review conditions, actions, and possible interactions between events — this helps prevent unexpected behaviors and keeps your operation flow stable. If you have questions or need help configuring your rules, contact CloudChat Support. Our team is ready to assist you in building intelligent and secure automations.

Last updated on Sep 02, 2026

How to send the ticket protocol number automatically in Cloud Chat

When to use it - You want the customer to receive the protocol number right at the start of the conversation - You need a unique reference per ticket for the customer to write down - You want to send the protocol number automatically — without the agent typing it manually Prerequisites - Be logged in as an administrator or CX Engineer - For a project with ClaudIA: have access to the Painel da ClaudIA (ClaudIA Panel) - For a project without AI: have permission to manage automations About this article When a conversation starts, it is good practice to send the protocol number to the customer automatically. In Cloud Chat there are two ways to do this, depending on how the project is set up. Available variables Both in automations and in the ClaudIA greeting, you can use dynamic variables with double curly braces: {{nome.da.variavel}}. In automations, typing {{ in the field brings up the options automatically. | Variable | What it returns | | --- | --- | | {{conversation.display_id}} | Protocol number (e.g.: #1042) | | {{conversation.id}} | Internal conversation ID | | {{contact.name}} | Contact's full name | | {{contact.first_name}} | First name | | {{contact.last_name}} | Last name | | {{contact.email}} | Email | | {{contact.phone}} | Phone | | {{contact.id}} | Internal contact ID | | {{agent.name}} | Full name of the assigned agent | | {{agent.first_name}} | Agent's first name | | {{agent.last_name}} | Agent's last name | | {{agent.email}} | Agent's email | | {{conversation.custom_attribute.CHAVE}} | Custom attribute of the conversation | | {{contact.custom_attribute.CHAVE}} | Custom attribute of the contact | :::info For custom attributes, replace CHAVE with the internal name of the attribute registered under "Configurações → Atributos Personalizados" (Settings → Custom Attributes). ::: Details at: How to use dynamic fields in Cloud Chat. Option 1 — Project with ClaudIA (AI handling the tickets) When ClaudIA is answering, all you need to do is add the protocol variable to the AI greeting. Variable to use {{conversation.display_id}} How to set it up 1. Go to the AI greeting setting in the Painel da ClaudIA 2. Insert {{conversation.display_id}} into the welcome message 3. Save and test Greeting example Olá! Seu número de protocolo é {{conversation.display_id}}. Como posso te ajudar? Option 2 — Project without AI (human agents only) Create an automation in Cloud Chat to send the protocol number as soon as the conversation is opened. How to set it up 1. In Cloud Chat, go to "Configurações → Automações" (Settings → Automations) and create a new automation 2. Set the trigger: Conversation Created 3. Set the action: "Enviar uma mensagem" (Send a message) 4. In the message field, insert {{conversation.display_id}} 5. Save and enable the automation Message example Olá! Seu protocolo de atendimento é {{conversation.display_id}}. Summary | | Option 1 — With ClaudIA | Option 2 — Without ClaudIA | | --- | --- | --- | | Where to set it up | AI greeting (Painel da ClaudIA) | Cloud Chat automations | | Trigger | Start of the conversation with the AI | Conversation Created event | | Variable used | {{conversation.display_id}} | {{conversation.display_id}} | | Does it need a "Fluxo Controlado" (Controlled Flow)? | No | No | Notes :::success Tip: always include the protocol number in the first contact so the customer has a reference from the start. ::: - For details on dynamic variables: How to use dynamic fields in Cloud Chat - To create the automation for Option 2: How to manage automations in Cloud Chat - To understand automation events: How the events that trigger automations in Cloud Chat work - To integrate ClaudIA before setting up Option 1: How to integrate ClaudIA with Cloud Chat and add channels

Last updated on Sep 02, 2026

How to set a ticket limit per agent and assign tickets via Round Robin

When to use this - You want to limit the number of simultaneous tickets each agent can handle - You want to distribute tickets automatically across the team (round robin) - You want to set a different limit per agent or per team Prerequisites - Be logged in to Cloud Chat as an administrator About this tutorial In this article you will learn how to set the limit of parallel chats per agent and how to enable automatic ticket assignment via round robin. Instruction video: https://youtu.be/JLUTcrNXAEU Step by step Step 1 — Set the general limit for the account First, set the global limit (for the whole company) of open tickets that agents can have. 1. Go to Settings → Account Settings Image 2. Set the limit in the auto assignment per account section :::info Example: if you set the limit to 50, an agent can automatically receive at most 50 tickets in Open status at the same time. Manually, more tickets can be assigned beyond this limit. ::: Image Image :::warning Exception to the limit: if an agent has 50 tickets, marks one as pending, receives a new open ticket, and then the customer replies to the pending one (which goes back to Open), the limit will be exceeded. ::: Step 2 — Set a different limit for specific agents (optional) After setting the general limit, you can set an individual limit per agent. 1. Go to Settings → Agents 2. Select a user 3. Set the Auto assignment limit Image Step 3 — Enable Round Robin on the inbox Edit the desired inbox and click Enable auto assignment. Image Image Image :::success With the feature enabled, tickets are distributed in rotation among the available agents: each new ticket goes to the next agent in the queue, keeping the distribution balanced. - If an agent goes offline, tickets go to the remaining agents until they reach their limit - When an agent reaches the limit, they stop receiving tickets until they free up space - If no agent is online, tickets are distributed once agents come online ::: Step 4 — Enable Round Robin per team (optional) This configuration can also be done for teams. 1. Edit the team 2. Enable Auto assignment for the department Image Image Image 3. Follow the team setup process until Finish Image Notes - To create agents and assign individual limits: How to create a new user in Cloud Chat - To create and manage teams: How to create and manage teams in Cloud Chat - To set up SLA via automation after distributing tickets: SLA: service time metrics - To understand the agent status (Available/Busy/Offline) that affects round robin: Agent status in Cloud Chat

Last updated on Sep 02, 2026

How to configure CSAT (by channel or automation) and view results

When to use - You want to enable automatic satisfaction surveys in Cloud Chat conversations - You want to send CSAT conditionally — only to certain teams, channels, priorities, or situations — using automation - You need to understand when and how CSAT is recorded in relation to the agent - You want to view and filter CSAT results on the dashboard Prerequisites - Being logged in as a administrator on Cloud Chat - Having at least one inbox configured About this tutorial In this article, you will learn how the CSAT (Customer Satisfaction Score) works in Cloud Chat, how to enable it (by channel or automation), and where to view the results. Instructional video: hhttps://youtu.be/DVyBFMw9YG8 How Cloud Chat's CSAT works CSAT can be sent in two ways (choose the one that makes the most sense for your operation): - By inbox (default): enabling CSAT on an inbox automatically sends the survey to 100% of resolved tickets in that inbox. It’s toggle — either send to all, or to none. - By automation (conditional): an automation rule with the Send Satisfaction Survey (CSAT) action allows you to choose when and to whom the survey is sent — for example, only to a specific team, channel, priority, or outside business hours. See more below under Send CSAT conditionally (via automation). The survey is a link leading to a page with a 1 to 5 question, with numbers AND emojis, and offers the customer the option to comment in more detail (not mandatory). :::info It is not possible to customize the appearance or questions of the survey beyond this — we are always updating. What you can control is when and to whom the survey is sent, using automation (see below). ::: How the agent is recorded in reports Whenever a CSAT is recorded, it is linked to the last agent assigned to the conversation at the time the customer responds to the survey. - Assigning a new agent replaces the previous one for CSAT recording purposes - Removing the agent still links the CSAT to the last assigned agent - Changing/removing agent after recording does not alter the record - If no agent was assigned, the CSAT is not linked to any agent How to enable CSAT per inbox This is the default method: when enabled, CSAT is sent to all resolved tickets in the inbox. Step 1 — Access inbox settings 1. Go to Settings 2. Navigate to Inbox and select the desired inbox Step 2 — Enable CSAT Scroll to the bottom of the settings and activate the Enable CSAT option on the channel. Send CSAT conditionally (via automation) :::warning For conditional sending to work as expected, disable the "Enable CSAT" option on the inbox (in Settings → Inbox). If it remains enabled, the inbox will send the survey to 100% of resolved tickets, regardless of automation conditions — thus, conditional control will have no effect. Even if both methods are active simultaneously, no duplicate sending occurs: in the same conversation, the customer receives at most one survey. ::: Besides sending via inbox (which covers 100% of resolved tickets), you can set up an automation rule to send CSAT only in specific situations. This is useful for example to: - Send the survey only to a specific team (e.g., Sales team only, not Support) - Send only in certain channels, priorities, or tags - Send outside business hours, or under any other condition you need - Avoid re-sending in tickets that reopen and close multiple times — the survey is sent at most once per conversation Conditional sending uses the action Send Satisfaction Survey (CSAT), available among other automation actions (such as Resolve Conversation or Add Tag). Step 1 — Create a new automation rule 1. Go to Settings and select Automation 2. Click Add automation rule and give it a Name Step 2 — Define trigger and conditions 1. Under Event, choose Conversation Updated 2. Under Conditions, add Status equals Resolved — this triggers the survey upon ticket resolution 3. (Optional) Add other conditions like Team, Inbox, Priority, or Tag to refine when the survey is sent. 4. Under Actions, select Send Satisfaction Survey (CSAT) — no additional setup needed 5. Click Create :::info The survey is not sent when: the conversation is not resolved, the contact is blocked, the conversation is part of a campaign, the channel does not allow CSAT (e.g., public comments on Instagram or posts on X/Twitter), or the conversation has already received a survey. ::: Customizing CSAT for WhatsApp For those using the native WhatsApp API (not applicable to Twilio), we offer an option to send CSAT directly within the app. As soon as the conversation is closed, the customer receives the survey natively on WhatsApp — no external link, no redirection. They can respond right there in a simple, integrated manner. :::warning Meta currently does not support all message types on WhatsApp Web — only on standard devices (Android and iOS). ::: The language in which CSAT is sent matches the language set in the Cloud Chat account. How to view results Step 1 — Access reports 1. Go to Reports 2. Click on CSAT Step 2 — Filter results You can filter by: - Date - Agent - Team - Inbox or Score To open a specific ticket, click on the ticket number. :::info Important: CSAT is recorded based on the date the customer responds, not the ticket creation date. CSAT measures the customer's final experience — after resolution. ::: Additional notes - Automatic ticket resolution also triggers CSAT sending: Automatic ticket resolution and Account settings: language and automatic resolution - To set up a single conversation on WhatsApp (affects CSAT sending): How to set up the Single Conversation feature on WhatsApp - To extract CSAT data in reports via API: How to batch export data via API (Data Extract API)

Last updated on Sep 02, 2026

How to set up SLA and service time metrics

When to use it - You need to set deadlines for first response, next response, and resolution on tickets - You want to visually track whether a ticket is within or outside the SLA - You want to apply SLA policies automatically based on tag, priority, or agent Prerequisites - Be logged in as an administrator (only admins manage SLA) - Have the desired event mapped in an automation — see How to manage automations in Cloud Chat About this article The SLA (Service Level Agreement) lets you define and track service time metrics. It is controlled by SLA policies that set limits for responses and resolution, applied to tickets through automations. The goal is to ensure predictability, control, and monitoring of service time. Access and permissions SLA policy management lives under Settings. :::warning Only users with the Administrator profile can: - Create SLA policies - Edit policies - Delete policies - Create automations with SLA policies Other profiles do not have access to these actions. ::: SLA policies Configured metrics Admins can create policies with: - First Response Time (FRT) — first response time - Next Response Time (NRT) — next response time - Resolution Time (RT) — total resolution time Rules and validations :::error The resolution time cannot be lower than: - The first response time - The next response time If this rule is not followed, the policy will not be saved. ::: Editing :::warning When a policy is already in use and gets edited: - The only value that can be changed is the NRT — and not immediately, but on the next message ::: Deletion When you delete a policy: - It stops working immediately - Tickets that used that policy no longer have the SLA associated with them :::info Deletion is the only way to remove a policy from a ticket after it has been applied. ::: How to create a policy Settings → SLA → Create a new SLA Policy → Fill in the fields (Name, description, FRT, NRT, RT) → Create Once created, the next step is to add it to an automation. Applying the SLA through automations :::warning SLA policies do not work on their own — to apply one to a ticket, you must set it up through Automations. ::: Setup Under Automations, create triggers to apply policies based on: - Tag - Priority - Agent - Others When the trigger condition is met, the policy is applied automatically. Important rules :::warning - A policy can only be added through an automation - Once added to a ticket: - It cannot be removed through an automation - Through an automation, it can only be replaced by another one - Complete removal only happens if the policy is deleted from the system ::: How SLA times are calculated The metrics are calculated dynamically, taking into account the ticket status, who is interacting, and automatic pauses. First Response Time (FRT) Definition: the time between the customer's first message and the first reply from a human agent. Calculation rules: - Starts when: the customer sends a message and the ticket is not in Pending status - Ends when: a human agent sends the first reply - If the policy is applied after the first response has already happened → FRT is not taken into account - If ClaudIA takes over the service → the time is frozen while the AI is working Next Response Time (NRT) Definition: the time between a customer message and the human agent's next reply, after the first response. Calculation rules: - It only comes into existence after the FRT has been completed - Starts when the customer sends a new message - Ends when a human agent replies or the ticket is resolved - Every time the agent replies → the NRT is reset (it shows up again when the customer sends a new message) - Visually: - At some moments you see FRT and RT - At others, NRT and RT - At others, only RT (when the last message came from the agent) - It is paused while ClaudIA is handling the ticket Resolution Time (RT) Definition: the total time to resolve the ticket, counting only active periods. Calculation rules: - Starts when the ticket is created - It is cumulative, with pauses - Ends when the ticket is marked as resolved - It is fixed — it always exists while the ticket is not resolved - It can never be lower than the FRT or the NRT States that pause the SLA :::info Times are frozen when the ticket is being handled by the AI (ClaudIA) or when the ticket is Snoozed. During that period, no time is added — the SLA remains associated with the ticket, but paused. Changing the ticket to Pending does not pause the SLA — the deadlines keep counting normally. When you Snooze a ticket, the SLA is paused automatically (within up to 5 minutes): the snoozed period is discounted from the deadlines when the conversation resumes. ::: Behavior with ClaudIA When the AI (ClaudIA) is working on the ticket, the SLA behaves in a specific way. :::info Pause rules with the AI: - If the AI is replying as the agent → all SLA times are paused - That time is not counted as first or next response - Counting resumes when: - A human agent takes over - The ticket leaves the paused state This ensures the SLA does not penalize the time the AI is working — only human interactions are taken into account. ::: Viewing the SLA on the ticket General rules - Active SLA → displayed normally on the ticket - Paused SLA → still visible on the ticket, showing the deadlines recorded at the moment of the pause This applies when the ticket is being handled by ClaudIA or Snoozed. Since the paused period is discounted when it resumes, the deadline shown during the pause is provisional — it is recalculated (extended) when the SLA starts counting again, for example when a human agent takes over or the snoozed conversation receives a new message. Left side — Dynamic times The left side shows the SLA times according to the status and stage of the service. How the times are displayed - No agent assigned → shows FRT (left) and RT (right) - Once the FRT exists → shows NRT (left) and RT (right) Important rules - If the policy is added after the FRT has already happened → the FRT is neither taken into account nor displayed - The NRT is variable — reset every time the agent replies - The only fixed time throughout the whole cycle is the RT Visual behavior (timers) - Within the deadline → the time counts down, displayed in green - Overdue → the time starts counting up, displayed in red Hover When you hover the mouse: - Within the deadline → shows "how much time is left before it expires" - Overdue → shows "how long ago the deadline was missed" - If only a dash (-) appears → "the next response is the customer's" Center area — History Shows when the policy was added and that it came through an automation. Right side — Text details Shows the deadlines and status of each metric in a clear, text-based format. Metrics displayed - They vary depending on the conversation status: FRT, NRT, RT - The RT is the only fixed one Format Each metric shows: - The SLA due date and time - A text status below it: "Due in X" or "Overdue by about X" Colors - Within the deadline → green - Overdue → red Pause rules When the SLA is paused: - It stays displayed, with the deadlines recorded at the moment of the pause - The deadlines are recalculated when it resumes, discounting the paused period Summary of the important rules - Only administrators manage SLA policies - Deleted policies → stop working immediately - Edits only affect new tickets - The SLA is only applied through automations - The information visible to agents is dynamic - Once a policy is applied: - It cannot be removed through an automation - It can only be replaced by another one - The RT can never be lower than the FRT or the NRT - A paused SLA stays visible; the deadlines are recalculated when it resumes, discounting the paused period Why do the time tabs show zeros? The time metrics come in two versions: elapsed time (24h) and business hours. The business hours version is only calculated if the inbox has business hours enabled — without that, the value is always 0, which is why the tabs show zeros. How to fix it: Settings → Inboxes → select the inbox → Business hours tab → turn on availability, set the hours for each day, and confirm the time zone. From then on, new tickets start populating the business hours tabs. Notes - To create the automation that applies the SLA: How to manage automations in Cloud Chat - To understand when ClaudIA is working (and the SLA is paused): How ticket handover to Level 2 (N2) works with ClaudIA - To set up the ticket limit per agent (which impacts the NRT): How to set up a ticket limit per agent and assignment via Round Robin - To understand how automatic ticket closing works: How automatic ticket resolution works

Last updated on Sep 02, 2026

Inactivity Follow-up Message

How does it work? The Inactivity Follow-up feature allows Cloud Chat to automatically send a message to the customer when a conversation remains unanswered for a certain period. This message acts as a reminder before the system automatically closes the ticket through Auto-Resolve Tickets. Without this automatic follow-up, some issues may occur: - Conversations closed without notice, creating a feeling of abandonment for the customer - Customers get distracted and do not respond in time - Unnecessary ticket reopens - Increased volume and rework for the support team With follow-up, the system sends a reminder before closing the conversation, giving the customer a last chance to continue the interaction. Practical example An agent replies to the customer at 10:00 AM. The customer does not respond. If the follow-up is set for 60 minutes, at 11:00 AM the system automatically sends a message such as: "Hello! Do you still need help? If you have no further questions, this ticket will be closed automatically soon." - If the customer responds, the conversation continues normally. - If the customer does not respond, the auto-resolve will close the ticket after the configured time. Operating rules Certain rules determine when the follow-up can or cannot be sent: - The feature is enabled per inbox - Inactivity time is configured in minutes and must be a multiple of 5 (e.g., 5, 10, 15, 30, 60, 120) - For follow-up to work, the account must have auto-resolve tickets enabled. If not configured, the follow-up message configuration section will not appear in the interface. - The follow-up message must be sent within a time less than the automatic ticket resolution - Follow-up is only sent if the last public message was from a human agent - Only one follow-up is sent per inactivity cycle Important about sending time The follow-up message may be delayed up to 5 minutes from the configured time. This occurs because the inactivity check is performed periodically, every 5 minutes, via an automated process (cronjob). That is, the system does not monitor conversations in real time but in verification cycles. For example: if follow-up is set for 60 minutes, the message might be sent between 60 and 65 minutes after the last agent response. When follow-up is not sent The system will not send follow-up in the following cases: - The conversation has already been resolved - The conversation is deferred/pending - The last message was sent by bot or automation - The customer responded before the configured time elapsed - A follow-up has already been sent in that cycle If the customer responds after the follow-up and the conversation becomes inactive again, a new follow-up may be sent in a new cycle. Flow How to enable and configure the message Follow the steps below to enable follow-up on an inbox. 1. Access the settings In the Cloud Chat side menu: 1. Go to Settings 2. Click on Inboxes 3. Select the inbox you want to configure 2. Locate the follow-up section Within the inbox settings, look for: Inactivity Follow-up Message Note: If this section does not appear, check if auto-resolve tickets is active. 3. Enable the feature Activate the Inactivity Follow-up Message option. Then configure the following fields: Inactivity Period (minutes) Set the amount of minutes the system should wait for a customer response before sending the follow-up. Rules: - Minimum of 5 minutes - Value must be a multiple of 5 - Must be less than the auto-resolve time Follow-up message Write the text that will be automatically sent to the customer. Example message: "Hello! Do you still need help? If you have no further questions, this ticket will be closed automatically soon." 4. Save the configurations After filling in the fields: Click Update to apply changes. From this moment, the follow-up will be active for new conversations in that inbox. Test tip for the functionality To verify if everything is working properly: 1. Set a short time (e.g., 5 minutes) 2. Start a test conversation 3. Wait for the automatic message to be sent Frequently asked questions Does the follow-up appear as a message from the agent? Yes. The message appears as if sent by the agent, but with a special message type that does not reset the auto-resolve timer. If I disable follow-up, are the messages already sent removed? No. The messages already sent remain in the conversation. Only new follow-ups will not be sent. Does follow-up work on all channels? Yes. The feature works on any channel, as long as it is enabled. Can I set different times for each inbox? Yes. Each inbox has independent configuration, allowing different settings for each operation.

Last updated on Sep 02, 2026

How automatic ticket resolution works

When to use - You want to automatically close tickets with no activity after X hours - You need to understand under which conditions a ticket is closed vs. kept open - You are investigating why a ticket was not closed automatically Prerequisites - Be logged in as an administrator About this article The platform offers an automatic ticket resolution feature that allows the recurring closing of inactive conversations, based on configurable conditions and time periods. Where to configure Step 1 — Access Account Settings 1. Go to Settings → Account Settings 2. Locate the field After how many hours should a ticket resolve itself if there is no activity 3. Set the number of hours of inactivity after which tickets should be resolved The setting applies to all tickets that meet the conditions below. Conditions for automatic resolution :::info A ticket will only be resolved automatically if all of the following conditions are met: - The ticket status is Open - The last message in the conversation is from an agent or an automation — automated messages also restart the countdown. Internal/private notes and follow-up messages do not restart it ::: Statuses that do NOT allow automatic resolution :::warning Tickets in Pending or Snoozed status are not resolved automatically. If these tickets are reopened, the time configured for auto-resolution starts counting from the reopening date. ::: Notes - To configure name/language and the automatic resolution time: How to configure account language and automatic ticket resolution - To understand how CSAT is triggered when the ticket is resolved: How to configure CSAT per channel and view results - To understand what each ticket status means: Ticket statuses in Cloud Chat

Last updated on Sep 02, 2026

How to manage automations in Cloud Chat

When to use - You want to standardize and automate repetitive support actions (assigning a tag, transferring to a team, sending a message) - You want to react automatically to conversation events (created, updated, new message, reopened) - You want to fill custom attributes or trigger webhooks via rules Prerequisites - Be logged in as an administrator or CX Engineer - Have the custom fields, tags, and teams already created if you want to use them in actions About this article Cloud Chat lets you create automations to standardize and speed up support — reducing manual work and ensuring consistency. Based on events and conditions, you configure automatic actions such as filling fields, assigning conversations, sending messages, etc. How to access and manage automations 1. Go to Settings 2. Open Automations 3. On this screen you can: - Create new automations - Edit existing rules - Clone automations - Delete automations - Enable / disable (via the status toggle) How to create an automation Click Add Automation Rule and fill in: - Title — identifying name - Description (optional) — summary of what it does - Event — the automation trigger: - Conversation Created - Conversation Updated - Message Created - Conversation Opened - Conditions — rules that must be true (e.g., agent = X, team = Y) - Actions — what happens when the criteria are met (e.g., add tags, send a message) Finish by clicking Create, and keep the status Active so it runs. Available events 1. Conversation created — whenever a new conversation starts 2. Conversation updated — when there is a relevant update to the conversation 3. Message created — when a new message is created (by the agent, user, or customer) 4. Conversation opened — when a conversation that was resolved, pending, or snoozed is resumed :::info To understand how each event works and its best practices: How the events that trigger automations work in Cloud Chat. ::: Available conditions per event When configuring, define conditions that must be true for the rule to run. The options vary by event. :::warning Some conditions such as Country are not available for all contacts — they depend on the browser/channel passing that information along. Many channels do not have these attributes available and/or users choose to block them. ::: :::info Custom attributes (of conversations or contacts) can be used as a condition in any of the events. ::: Conversation Created Triggered as soon as a new conversation starts. - Status, Browser Language, Email Subject, Country, Phone Number, Referrer Link, Email, Inbox, Conversation Language, Priority Conversation Updated Triggered whenever an existing conversation is modified. - Conversation Tag, Status, Browser Language, Email Subject, Country, Referrer Link, Phone Number, Assignee, Team, Email, Inbox, Conversation Language, Priority Message Created Activated when a new message enters the conversation. - Conversation Tag, Message Type (incoming/outgoing), Message Content, Email, Inbox, Conversation Language, Phone Number Conversation Opened When a resolved/pending/snoozed conversation is reopened. - Browser Language, Email, Email Subject, Country, Referrer Link, Assignee, Phone Number, Team, Inbox, Conversation Language, Priority Available actions - Assign to a specific agent - Route to a team - Add labels (tags) - Fill in custom fields - Send automatic messages or attachments - Resolve, mute, or snooze the conversation - Send email notifications - Trigger webhooks - Change custom fields of conversations - Change custom fields of contacts You can combine multiple actions in a single rule. Using custom fields in automations Cloud Chat lets you create Custom Fields (custom attributes) that store information specific to a conversation or contact. They are configured in Settings → Custom Attributes. Details at: How to create custom fields for contacts and conversations. In an automation, you can fill in or change these fields with fixed values based on the conditions. Example: When the conversation is marked as resolved and the team is "Tech", fill the Motivo do Contato (Contact Reason) field with Pedido de Suporte (Support Request). Using dynamic attributes in automations Besides fixed values, you can fill fields with dynamic values using double curly braces. These values are replaced at execution time based on the context. Examples: - {{conversation.display_id}} — public ID of the conversation - {{inbox.name}} — name of the inbox Details: How to use dynamic fields in Cloud Chat. Practical example Configure an automation to fill a referência_interna field with the conversation ID: Action: Fill referência_interna with {{conversation.display_id}}. Important tips when configuring Be careful with "equal to FALSE" :::warning It is recommended to avoid the "equal to FALSE" operator — it can cause unexpected behavior. Prefer "not equal to TRUE". ::: Avoid conflicts with ClaudIA :::error Some automations can interfere with ClaudIA's rules. Before enabling one, make sure it does not change statuses, fields, or flows used by ClaudIA — it can interrupt or compromise her responses. Details at: How to integrate ClaudIA with Cloud Chat and add channels. ::: Difference between "AND" and "OR" in conditions - AND — all conditions must be true simultaneously E.g.: Status = Open AND Priority = High → only triggers if both are true - OR — one being true is enough E.g.: Status = Open OR Priority = High → triggers in either scenario Be careful with too many actions in a single automation :::warning Too many actions in one automation can lead to: - Chained changes that are hard to control - Risk of automatic loops - Difficulty identifying what triggered the rule Best practice: keep it simple and direct. If you need many actions, split them into more than one automation. ::: Watch out for logic across more than one automation :::warning Automation concurrency — when two automations modify the same fields with: - The same event - The same condition - The same action Data may be incorrectly overwritten. Always validate additional conditions so that only one rule is applied. ::: Empty fields An automation should never leave fields empty. Before updating/deleting an important attribute (agent, custom attribute): - If the field cannot receive a value → the automation should not run - If there is already a value → evaluate whether to keep or complement it, but never overwrite it with an empty value - Before deleting anything → check that it is not being used in other automations Webhooks — how to identify the status? In a conversation you can track the webhook delivery status as an audit trail. - Sent successfully — antenna icon at the bottom of the message - Delivery failed — triangle with an exclamation mark in the center - Webhook not executed — no icon at all, meaning the automation did not run (it may be disabled or misconfigured) Notes - To understand the order of events in detail: How the events that trigger automations work in Cloud Chat - To create custom fields before using them in conditions/actions: How to create custom fields for contacts and conversations - To configure SLA via automation: SLA: Service time metrics - To configure ClaudIA on new channels without breaking anything: How to integrate ClaudIA with Cloud Chat and add channels

Last updated on Sep 02, 2026

How to know which automation was triggered in a ticket

When to use - You want to audit which automations ran in a specific conversation - A ticket behaved unexpectedly (tag, assignment, status, or field changed on its own) and you want to find out which rule caused it - You are validating if a newly created automation is firing as expected Prerequisites - Access for agent, administrator, or CX Engineer to Cloud Chat - The conversation you want to investigate open on the screen About this article Whenever an automation executes an action in a conversation, Cloud Chat logs this in the ticket timeline as an activity message (those gray lines). These messages show the name of the rule that ran in the format Automation System (automation name) — so, it is possible to identify which automation was triggered directly within the ticket. How to identify the automation that ran Step 1 — Make sure activity messages are visible Automation actions appear as activity messages (in gray) on the timeline. If you hid these messages at some point, the preference is saved in your profile and they do not appear. To show them again, click the eye icon in the conversation action bar (at the top). Full step-by-step: How to show or hide activity messages in the conversation. :::info Hiding/showing only affects the display — all activities continue to be recorded. When redisplaying, the entire history appears in chronological order. ::: Step 2 — Locate the "Automation System" messages On the timeline, look for activity messages that start with Automation System. The name in parentheses is the automation that triggered, and the text describes the executed action. Examples: - Assigned to ClaudiA FAQ by Automation System ([Cloud Humans] Trigger for Assignment) Automation actions that generate activity messages include agent/time assignment, status change (resolve/reopen), custom attribute modification, and tag addition. :::info The activity message shows the exact moment the action occurred. Cross-reference this time with the rule’s event (Conversation Created, Message Created, Conversation Updated, or Conversation Opened) to confirm why it triggered there. ::: Notes - If you do not find any Automation System messages, it indicates that no automation ran in that conversation — review the conditions and event of the rule to understand why it did not trigger. - When more than one rule modifies the same fields with the same event, there can be overwrites. Avoid conflicts between automations to facilitate tracking. More details at: How to manage automations in Cloud Chat - To understand the order in which events trigger rules: How events trigger automations in Cloud Chat

Last updated on Sep 02, 2026

Closing message on automatic resolution

When to use it - You want the customer to receive a goodbye message when the ticket is closed automatically due to inactivity - Your customers complain that the conversation "disappears" without notice when nobody replies - You already use the inactivity follow-up message and want to close the cycle with a final notice Prerequisites - Be logged in as an administrator - The account must have automatic ticket resolution set up — without it, the fields do not show up in the inbox About this article Automatic resolution closes tickets that have been idle for X hours. Until now that closing was silent: the ticket disappeared from the queue and the customer was left not knowing whether the conversation was over. With the closing message, Cloud Chat sends a text that you configure at the moment the ticket is resolved automatically — ending the conversation clearly and leaving the door open for the customer to come back. It is the last stage in the timeline of an inactive conversation: 1. The agent replies and the customer does not come back 2. Once the follow-up time has passed, the follow-up message goes out ("do you still need help?") 3. Once the auto-resolution time has passed, the ticket is resolved and the closing message goes out (this article) The two are independent: you can use just one, both, or neither. Step by step Step 1 — Open the inbox 1. In the side menu, go to "Configurações" (Settings) 2. Click "Caixas de entrada" (Inboxes) 3. Select the inbox you want to configure Step 2 — Open the "Ciclo da conversa" (Conversation Cycle) tab In the inbox settings, click the "Ciclo da conversa" (Conversation Cycle) tab — it sits right after "Configurações" (Settings) and brings together the behaviors for communicating with the customer throughout the conversation: greeting, satisfaction survey, email continuity, creation via API, and the automatic follow-up and closing messages. :::info If the closing fields do not appear, check whether automatic ticket resolution is set up on the account. ::: Step 3 — Enable it and write the message 1. In "Enviar mensagem de despedida ao encerrar automaticamente" (Send a goodbye message on automatic closing), select "Habilitado" (Enabled) 2. Fill in the "Mensagem de encerramento" (Closing message) field with the text the customer will receive Example: Since we did not hear back from you, we are closing this conversation for now. If you need anything else, just reply here. Thank you! :::warning The message is required in order to turn the feature on. If you set it to Enabled and leave the text blank, Cloud Chat blocks saving and warns you on screen. ::: Step 4 — Save Click "Atualizar" (Update). From then on, the next automatic resolutions in that inbox will already go out with the goodbye message. When the message is NOT sent :::info The goodbye message only goes out when all of the conditions below are true: - The ticket was closed by automatic resolution due to inactivity — manual closing by the agent and campaign resolution do not trigger the message - The last reply sent to the customer came from a human agent — if the last one to speak was ClaudIA or an automation, the goodbye message does not go out (those flows have their own closing) - The customer did not reply between the resolution and the sending — if they reopen the conversation in that interval, the message is canceled - The channel accepts direct messages — public Instagram comments are left out ::: Notes - The message goes out after the ticket is already resolved. Because it is an outgoing message (from the agent), it does not reopen the conversation and does not restart the automatic resolution countdown. - CSAT keeps working normally: if the inbox sends a satisfaction survey, the customer receives the goodbye message and the survey, with no duplication — at most one survey per conversation. - The setting is per inbox. Each inbox can have (or not have) its own message. - Do not confuse this with ClaudIA's closing message. ClaudIA has its own closing, configured in the project (under "Ciclo de vida → Resolução Automática" (Lifecycle → Automatic Resolution)), with different texts for customers who reply and for those who do not reply to the follow-up. This article covers the closing from Cloud Chat, configured in the inbox, which applies precisely to conversations where a human agent was the last to respond. - For the message that goes out before the closing: Inactivity Follow-up Message (Follow-up) - To understand the automatic closing conditions: How automatic ticket resolution works

Last updated on Sep 09, 2026

End-to-end inactivity flow: which setting does what

When to use it - You want to understand which setting does what in the cycle of a stalled conversation — reminder, closing, farewell message and per-team timings - You want the conversation to go back to the right team when the customer replies after it was closed - You are setting up the inactivity flow for the first time and don't know where to start Prerequisites - Being logged in as an administrator - An inbox already set up; for the per-team timings, the teams already created About this article The "inactivity flow" is not a single screen: it is four independent settings that, together, form the timeline of a conversation left without an answer. This article is the map — it shows the order in which the pieces act, where each one lives and which article covers each of them in detail. At the end, it brings the recipe for sending the conversation back to the right team when the customer shows up again. :::info Snoozing ("Adiar") is not part of this cycle. Snooze is a deferral with a deadline, done manually or by an automation — see Snooze automations with a deadline. ::: The timeline | # | What happens | Where it is configured | Unit | Article | | --- | --- | --- | --- | --- | | 1 | The silence starts counting: support replied and the customer did not come back | — | — | Ticket statuses | | 2 | The reminder goes out ("do you still need help?") | Inbox → "Ciclo da conversa" (Conversation cycle) tab | minutes (multiples of 5) | Inactivity follow-up message | | 3 | The ticket is automatically resolved | "Configurações da conta" (Account settings) | hours | How automatic ticket resolution works | | 4 | The closing message (farewell) goes out | Inbox → "Ciclo da conversa" (Conversation cycle) tab | — | Closing message on automatic resolution | | 5 | A specific team uses timings of its own | "Times" (Teams) → "Sobrescritas" (Overrides) step | minutes | How to configure SLA, auto-resolution and follow-up per team | Steps 2 and 4 are optional and independent: you can use only the reminder, only the farewell, both or neither. Step 3, on the other hand, is the foundation — without automatic resolution configured on the account, the fields of steps 2 and 4 do not appear in the inbox. Which piece to change | You want to... | Change | | --- | --- | | Warn the customer before closing | The reminder (step 2) | | Close faster or slower | The account's automatic resolution (step 3) | | Avoid having support "disappear" without notice | The closing message (step 4) | | Give different timings to one team | The team's overrides (step 5) | | Turn the reminder off for one team only | The team's overrides, with the follow-up override active and no message (step 5) | | Never close due to inactivity | Leave the account's automatic resolution blank — this also turns off the reminder and the farewell | :::warning Watch out for one difference between the pieces: for the closing, a message sent by an automation also counts as support activity and keeps the countdown running. The reminder, however, is only sent when the last public message came from a human agent — if the last answer came from ClaudIA or from an automation, the reminder does not go out, but the closing still applies. ::: Sending the conversation back to the right team when the customer replies If the customer replies after the closing, the conversation reopens by itself — it does not get lost. What is usually missing is the routing: the conversation reopens in the team that was assigned at the moment of the closing, which may not be the team that should handle it now (for example, when you use one team only to hold the cases that went inactive). To solve this, use an automation on the reopening event: 1. Go to Configurações → Automações (Settings → Automations) and click Adicionar Regra de Automação (Add automation rule). 2. Under Evento (Event), choose Conversation Opened — it fires when a resolved, pending or snoozed conversation is picked up again. 3. Under Condições (Conditions), narrow it down to the case you want to handle — usually the inbox and the control tag of the inactivity flow. 4. Under Ações (Actions), use Atribuir Equipe (Assign team) to send the conversation to the team that should handle it and Remover Tag (Remove tag) to clear the inactivity marking. 5. Save it with the status Ativo (Active). :::info In inboxes with an active bot (ClaudIA), the customer's reply in a closed conversation first moves the conversation to pending, and it is the bot that takes it to open. The reopening automation runs when it actually opens. ::: For details on how to create, clone and order rules, see How to manage automations in Cloud Chat. Notes - The reminder and closing checks run in 5-minute cycles — the trigger may happen a few minutes after the configured time. - The reminder must be configured with a time that is shorter than the account's automatic resolution; if the two coincide, the value is rejected. - Conversations with no team assigned always follow the account and inbox defaults, even if overrides exist on other teams. - Only one reminder is sent per silence cycle. If the customer replies and the conversation stalls again, a new cycle starts.

Last updated on Sep 09, 2026

Pending as "Waiting for the Customer": Automatic Reopening, Follow-up, and Paused SLA

When to Use - Your operation marks conversations as Pending to wait for a customer response, and they end up forgotten in the queue. - You want the conversation to automatically return to the queue when the customer responds. - You do not want the waiting time for the customer to count against your response SLA. - You want follow-up and automatic closure to also include Pending conversations. Prerequisites :::warning This behavior is not enabled by default. It must be activated account by account by the Cloud Humans team — contact us through the support channel to enable it on your account. ::: - The conversation inbox cannot have an active support bot. How It Works What Changes When Enabled Three behaviors apply to Pending conversations. The conversation reopens when the customer responds. When a message is received from the contact, the Pending conversation switches to Open, notifies the assigned agent, and re-enters distribution and counters. Previously, it remained stuck: no notification, out of the queue, and out of the metrics. Follow-up and automatic closure now include Pending. They follow the same timeframes already set for Open conversations. No new timeframe adjustments are needed. The response SLA pauses. While the conversation is Pending, the response SLA counter is paused. When it reopens, the SLA resumes, deducting the time it was waiting. What Does Not Change - The status label on the screen remains "Pending". The label change to something like "Waiting for Customer" has not been implemented yet. - Messages sent by the agent do not change the status. The conversation leaves Pending due to a customer message, manual action by the team, or automatic closure. - If the inbox has an active support bot, the conversation remains Pending. When the Behavior Is Disabled Follow-up, automatic closure, and SLA pause only apply to Open conversations, just like before. Notes :::info An SLA correction applies to all accounts, including those that have not enabled this behavior. Previously, the SLA of a conversation that was snoozed and then resolved could remain paused indefinitely and never be marked as completed. Now it is correctly finalized. If you monitor SLAs in reports, the number of completed SLAs will increase: these are existing records that were not previously visible, not new volume. :::

Last updated on Sep 22, 2026

Out-of-hours Notice Does Not Interrupt Ongoing Support

When to Use - Your team provides support after hours, and the customer receives an out-of-hours notice during the conversation. - The automatic notice contradicts the agent in front of the customer: the person responds, and at the same moment, an "we are out of hours" message is sent. - You want the decision to notify about the end of the shift to be made by the person handling the conversation. How It Works What Has Changed Previously, after hours, the automatic notice was sent after every customer message, regardless of who was handling the conversation. Now, the notice remains silent while the person assigned to the conversation is connected to the platform. When the Notice Resumes - When the assigned person logs out. The notice is sent on the next customer message. - When the conversation has no one assigned. What Counts as "Connected" It is the actual presence on the platform: the person has the Cloud Chat open and active. :::info The availability selector does not determine this. Marking yourself as available, or having the always available option enabled, does not silence the notice if you are not actually connected. Otherwise, someone who logs out at 6 PM would silence the notice forever. ::: AI agent assignment does not count. The notice text refers to people, so a conversation assigned to ClaudIA continues to receive the notice normally. Notes - Applies to all accounts, with no configuration needed. Nothing needs to be turned on. - The change only stops sending the message. No account will start receiving notices it didn't before. - Known case not yet covered: those who support with the Cloud Chat tab closed are not considered connected, so the notice may still be sent over that person, at most once a day. This is mapped as the next step.

Last updated on Sep 22, 2026

How to edit the body of your webhook in an automation

You can now customize the webhook body within CloudChat Automations. Simply craft the JSON in the format expected by the destination system, without needing an intermediary tool just to convert data. If you leave the body blank, CloudChat will continue sending the default format. How to set up 1. Go to Settings > Automations and create or edit a rule. 2. Choose the event (for example, conversation created or conversation updated) and set the conditions. 3. Under Actions, select Send webhook and enter the destination URL. 4. In the Request Body (JSON) field, write the JSON using the variables below. 5. Save. Variables For custom attributes, replace KEY with the attribute key as registered in CloudChat. Contact - `{{ contact.id }}`: Contact ID - `{{ contact.name }}`: Full name - `{{ contact.first_name }}`: First name - `{{ contact.last_name }}`: Last name - `{{ contact.email }}`: Email - `{{ contact.phone_number }}`: Phone number - `{{ contact.custom_attribute.KEY }}`: Contact's custom attribute Conversation Agent - `{{ agent.id }}`: Agent ID - `{{ agent.name }}`: Name - `{{ agent.email }}`: Email Conversation - `{{ conversation.display_id }}`: Conversation number displayed on the screen - `{{ conversation.id }}`: Internal conversation ID - `{{ conversation.channel }}`: Channel (e.g., `Channel::Whatsapp`) - `{{ conversation.contact_name }}`: Contact's name - `{{ conversation.custom_attribute.KEY }}`: Conversation's custom attribute - `{{ conversation.assignee.name }}`: Name of the agent the customer sees - `{{ conversation.assignee.first_name }}`: Agent's first name - `{{ conversation.recent_messages }}`: Latest messages in the conversation Inbox and Account - `{{ inbox.id }}`: Inbox ID - `{{ inbox.name }}`: Inbox name - `{{ account.id }}`: Account ID - `{{ account.name }}`: Account name Specifications Always use | json after the variable. It automatically adds quotes and handles accents, quotes, and line breaks. If the field is empty, it sends null. - Correct: "name": {{ contact.name | json }} - Incorrect: "name": "{{ contact.name }}" - Incorrect: "name": {{ contact.name }} Example: { "email": {{ agent.email | json }}, "ticket": {{ conversation.display_id | json }}, "client": {{ contact.name | json }}, "channel": {{ inbox.name | json }} }

Last updated on Sep 23, 2026

Add or Remove Contact Tag via Automation

When to Use - When you want to segment your database without manually tagging each contact. - When you want every customer who opens a conversation about cancellation to be marked as churn risk and potentially enter a retention campaign afterward. - When you want to mark as detractor anyone who responds with a low CSAT. Prerequisites - Access to Settings → Automations. - The tags you will use are already created in your account. Step-by-step 1. Go to Settings → Automations and create a new automation, or open an existing one. 2. Choose the event. Both actions are available for all events, including CSAT responded. 3. Under Actions, select Add Tag to Contact or Remove Tag from Contact. 4. Select the tags in the multi-select field. 5. Save the automation. What each action does - Add Tag to Contact — adds the tag to the contact's existing tags. It never replaces previous tags. - Remove Tag from Contact — removes only the tags you selected in the action. :::info Until now, an automation could only tag the conversation. To mark the contact, someone had to open the contact and apply the tag manually, which made automatic segmentation impossible. ::: :::warning There is no action to clear all tags from a contact at once. Removal only deletes the tags listed in the action. ::: Notes - Contact tags and conversation tags are different. Campaigns segment by the contact tag. - If two automations modify the same contact simultaneously, they run sequentially, so one does not overwrite the tag just applied by the other.

Last updated on Oct 06, 2026

Time-based automations: customer without reply, conversation without answer and idle status

When to use - Send a reminder when the customer goes quiet after your reply (e.g., no answer in 4 hours) - Alert the team, change the priority or reassign when the customer wrote and nobody answered within X minutes - Resolve or reassign a conversation that has been sitting in Pending (or another status) for days - Assign the conversation to the last human agent who talked to the customer - Make a rule run only on private notes, or never on private notes Prerequisites :::warning A time-based rule acts on its own on every conversation that matches its conditions. Before using actions such as Resolve conversation or Send Message, start by limiting the rule to a single Inbox and follow the first results. ::: About this article Until now, every automation rule ran at the moment of the event (conversation created, message created, etc.). The When this rule runs field now has a second group, After a while, with three triggers that wait for a set time before acting. This article also covers two additions that apply to any rule: the Last responding agent option in the Assign Agent action and the Private Note condition. For the basics of creating and editing rules, see How to manage automations in Cloud Chat. To understand each event, see How the events that trigger automations work. Step by step Step 1 — Open a new rule Go to Settings → Automation and click Add Automation Rule. Fill in the Rule Name and the Description. Automation screen with the Automation menu and the Add Automation Rule button highlighted Step 2 — Pick the trigger in "When this rule runs" The field has two groups: As soon as it happens (the usual events) and After a while, with the three new triggers: | Trigger | When the clock starts | When the actions run | | --- | --- | --- | | Customer hasn't replied | When an agent or ClaudIA sends a reply to the customer | If the customer does not write again within the time set. Runs once per silence | | No teammate has replied | When the customer writes and nobody on the team has replied yet | If no reply from an agent or ClaudIA arrives within the time set | | Conversation stays in a status | When the conversation enters the status chosen in the conditions | If it is still in the same status at the end of the time set | When this rule runs field open, with the After a while group highlighted Step 3 — Set the wait time Next to the trigger, fill in for + number + unit (minutes, hours or days). The wait goes from 10 minutes to 30 days. Right below, a sentence explains when the clock starts for the chosen trigger. Customer hasn't replied trigger with the 4-hour wait highlighted Step 4 — Adjust the conditions Each trigger comes with a suggested condition, which you can change: - Customer hasn't replied → Proactive / Dispatch equal to False, so customers who only received a campaign are not chased - No teammate has replied → Status equal to Open - Conversation stays in a status → Status equal to Pending (change it to the status you want to watch) Rules for each trigger: - Customer hasn't replied and No teammate has replied accept conversation conditions (status, inbox, team, tags, priority, assignee, etc.), but not message conditions (content, message type, private note) or the "changed" operator. - Conversation stays in a status accepts only Status and Inbox, joined by AND. Status must be Equal to a specific status (not "All"). Conversation stays in a status trigger with the Status equal to Pending condition highlighted Step 5 — Choose the actions and save Add the actions (e.g., send a message, add a tag, resolve the conversation, assign an agent or team, send a WhatsApp template) and click Create. In the automation list, the rule shows a badge with the wait time, for example After 4 hours. :::info On time-based rules, the Replying agent option does not appear in Assign Agent, because there is no message that triggered the rule. Use Last responding agent. ::: How it works Last responding agent New option in the Assign Agent action, available in every event (Conversation Created, Conversation Updated, Message Created, Conversation Opened, Rating (CSAT) received) and in time-based rules. - Assigns the conversation to the agent who sent the most recent public reply. - Ignores private notes, customer messages, campaign messages and ClaudIA replies. - If the conversation is assigned to ClaudIA, it is not taken away from ClaudIA. - If no human agent has replied yet, the assignee does not change. Difference from Replying agent: that option exists only in Message Created and uses the author of the message that triggered the rule. Last responding agent looks at the conversation history, so it works in any event. Example: Conversation Updated + Status equal to Resolved + Assignee name is not present → Assign Agent: Last responding agent. Every conversation resolved without an assignee goes to whoever last helped the customer. Assign Agent action with the Last responding agent option highlighted Private note condition In the Message Created event (group As soon as it happens), there is the Private Note condition, with the values True or False: - True: the rule runs only when the message created is a private note (e.g., notify an external system by webhook whenever someone writes a note). - False: the rule ignores private notes (e.g., a rule that reacts to team messages and should not run on internal notes). Notes - Checked every 5 minutes. Time-based rules are checked every 5 minutes, so the actions may run a few minutes after the exact time. - Everything is checked again before acting. If in the meantime the customer replied, the team replied, the status changed or the conversation no longer matches the conditions, nothing happens. - Only applies from the moment the rule is saved. Conversations that were already idle before you created the rule are not included; they start counting when the clock restarts (a new reply, a new customer message or a new status change). Editing the trigger, the wait time or the conditions, or reactivating the rule, also restarts the count. - One run per episode. The rule runs once per customer silence, per unanswered wait or per entry into the status. For a sequence (e.g., a reminder after 4 hours and closing after 24 hours), create one rule for each step. The Customer hasn't replied count starts from the last message sent to the customer, including a reminder sent by an automation. - Safety limit: at most 5 runs of time-based rules on the same conversation every 24 hours, to prevent rules that trigger each other in a loop. - If you only need inactivity follow-up and closing, the built-in settings still apply: see End-to-end inactivity flow. Use time-based rules when you need your own conditions (inbox, tags, priority) or other actions.

Last updated on Oct 15, 2026