Rules create predefined actions that are automatically assigned to tickets. If the rule's conditions are met, the action is performed. In this article, you'll see a full list of all available rules' triggers, conditions, and actions with a short description and example for better understanding.
-
Agent Left Ticket Agent Opened Ticket Agent Rated Chat Started Incoming Call Started Message Added Message Group Added Outbox Mail Status Changed Queue Lenght Changed Ticket Created From Email Ticket Created Ticket Relation
Created Ticket Status Changed Ticket Tags Changed Ticket Transferred
List of "Apply when" rule triggers
Expand ALL
Agent Left Ticket
The rule takes action if a user (owner/admin/agent) closes a ticket he was viewing. The rule is not triggered if the user simply switches to another ticket or section of the agent panel.
Let's say you wish to notify the agent that he closes a ticket without any action (no answer, no ticket field updated, no TAG added, etc...). You would need to use this rule trigger.
The rule takes action if a user (owner/admin/agent) opens a ticket. The rule is not triggered if the user simply switches to another (already opened/viewing) ticket.
Let's say you wish to assign a ticket to the agent who opened it first. You would need to use this rule trigger.
The rule takes action if a user (owner/admin/agent) is rated after a chat or if his response within a ticket is rated by the recipient. The rule is not triggered if the customer refuses to rate or leaves a neutral rating.
Let's say you wish to be notified if a customer left a rating or you wish to TAG the ticket based on the customer's rating. You would need to use this trigger.
The rule takes action if a user (owner/admin/agent) picked up a chat (chat started). The rule is not triggered if the chat is only ringing.
Let's say you wish to TAG the chat (ticket) based on the customer's geolocation. You would need to use this trigger.
The rule takes action if a user (owner/admin/agent) picked up an incoming call (incoming call started). The rule is not triggered if the call is only ringing.
Let's say you wish to TAG the call (ticket) based on the customer's geolocation. You would need to use this trigger.
The rule takes action if a user (owner/admin/agent) or a customer adds a message (responses) to the ticket/chat. The rule is not triggered if the message is added by the system.
Let's say you wish to notify every user (owner/admin/agent) if a prioritized ticket gets a new response from the customer or automatically resolve a ticket once it is responded by any agent. You would need to use this trigger.
The rule takes action if any message group is added to any ticket including system messages, internal messages, agent responses, etc... With such a rule it is recommended to define a condition on "message group type".
Let's say you wish to be notified a ticket has been deleted by any agent or admin. You would need to use this trigger.
The rule takes action if the status of an outgoing email changes to error, sending, sent or waiting.
Let's say you wish to notify every admin of the system if an email failed to be sent. You would need to use this trigger.
The rule takes action if the number of waiting customers in the chat/call/tickets queue changes.
Let's say you wish to notify every agent if the queue exceeds a defined value. You would need to use this trigger.
The rule takes action if a new email is received (a new ticket is created). The rule is not triggered if an agent/admin sends email from the panel (creates a new ticket) or if the ticket is created from a different channel such as Facebook, Twitter, contact form, etc...
Let's say you wish to automatically transfer or delete a ticket if it is received from a specific sender email address. You would need to use this trigger.
The rule takes action if a new ticket is created (from all channels: email, chat, chat invitation, contact form, FB, Twitter, etc...). The rule is triggered also if an agent/admin sends email from the panel (creates a new ticket).
Let's say you wish to automatically TAG a ticket if it is created from a specific communication channel. You would need to use this trigger.
The rule takes action if any ticket relation is created (ticket is mentioned/merged/split).
Let's say you wish to automatically resolve a ticket if it is mentioned in any other ticket. You would need to use this trigger.
The rule takes action the status of a ticket (Answered, Calling, Chatting, Spam, Deleted, New, Open, Resolved, Postponed) is changed.
Let's say you don't wish to let agents to resolve a ticket without adding any TAG. You would need to use this trigger.
The rule takes action if a TAG is added or removed from any ticket.
Let's say you wish to automatically transfer, postpone or resolve a ticket if a specific TAG is added. You would need to use this trigger.
The rule takes action if a ticket is transfered to another department or assigned to any user (agent, admin, owner).
Let's say you don't wish to let agents to transfer a ticket without adding any TAG. You would need to use this trigger.
Additional "Apply When" triggers available for TIME RULES ?
Ticket Older ThanThe rule takes action if a ticket is older than the specified time (created the specified time ago).
Let's say you wish to be notified about a ticket that has not been resolved within a required time range. You would need to use this time rule trigger.
The rule takes action if the last status change has been done a longer than the specified time ago.
Let's say you wish to follow up on tickets where the customer did not respond within a required time range. You would need to use this time rule trigger.
The rule takes action if the ticket is going to reach its SLA within the defined time range.
Let's say you wish to TAG or somehow highlight a VIP ticket if it is about to be overdue. You would need to use this time rule trigger.
The rule takes action if a ticket is already overdue by a specified time.
Let's say you wish to investigate overdue tickets on your own. You would need to use this time rule trigger.
List of rule conditions
Expand ALL
Action Initiator Assigned Agent Status Context Variable Created From Contact Widget Current Date Current Day Current Time Custom Field Customer Group Ip Of Visitor Last Message Logged In User Role Requested By Requester
Company Is Requester Is From Ticket Assigned Ticket Changed Ticket Created Ticket Deleted Ticket Department Ticket Priority Ticket SLA Level Ticket Source Ticket Start Referrer URL Ticket Status Ticket Subject Ticket Tags
General conditions - available for most of the "Apply when" triggers:
Action InitiatorUsing this condition, you are able to limit the condition in such a way, that only the actions of a specific agent (initiator) could trigger this rule.
Is it also possible to define a specific agent who Did Not initiate the action in order to trigger the rule.
Using this condition, you are able to define the required status of the agent assigned to the ticket in order to trigger the rule.
Description goes here...
Further option goes here...
Description goes here...
Further option goes here...
Using this condition, you are able to define the required value of any context variable (system or custom).
Using this condition, you are able to define an exact date or date range/ranges within which the rule should be triggered.
You are able to define multiple dates or date ranges using the "Add condition group" option that works as an OR operator.
Using this condition, you are able to define an exact day/days when the rule should be triggered.
Further option goes here...
Using this condition, you are able to define an exact time or time range/ranges within which the rule should be triggered.
You are able to define multiple times or times ranges using the "Add condition group" option that works as an OR operator.
Using this condition, you are able to define the required value of any of your custom fields.
Using this condition, you are able to choose whether the customer (requester of the ticket) should or should not belong to a customer group in order to trigger the rule.
Using this condition, you are able to fully or partly specify the IP address of the visitor (requester of the ticket).
Using this condition, you are able to specify what should or should not be included in the last response (customer´s or agent´s) in order to trigger the rule.
Using this condition, you are able to define what should be the role of the action (Apply when) initiator.
Using this condition, you are able to specify the requester of the ticket (from whom the email should be to trigger the rule - customer's email address).
Using this condition, you are able to specify the company that the customer should be assigned with, in order to trigger the rule.
Using this condition, you are able to define the required geolocation of the ticket requester.
Using this condition, you are able to specify the ticket relation (assignment) with agents.
Using this condition, it is possible to defined the timerange in within the ticket (ticket´s status) should be changed in order to trigger the rule.
Using this condition, it is possible to defined the timerange in within the ticket had to be created in order to trigger the rule.
Using this condition, it is possible to defined the timerange in within the ticket had to be deleted in order to trigger the rule.
Using this condition, you are able to specify the department where the ticket should or should not be assigned.
Using this condition, you are able to specify ticket´s priority.
It is possible to choose between several priority levels - The highest priority: 64; The lowest priority: 1/64
Using this condition, you are able to define the required SLA level of a ticket.
Using this condition, you are able to specify the required source of the ticket (communication/support channel) in order to trigger the rule.
Using this condition, you are able to fully or partly specify the URL where the customer requested a ticket/chat/call.
This condition works with embeded forms (contact forms, chat/call/invitation buttons, etc...)
Using this condition, you are able to specify the required ticket status in order to trigger the rule.
Using this condition, you are able to fully or partly specify what should or should not be included in the subject of the ticket.
Using this condition, you are able to fully or partly specify which TAGs should or should not be added to the ticket in order to trigger the rule.
Additional condition - available for the "Agent rated" trigger:
Agent Rating TypeUsing this condition, you are able to specify the required type of the rating (positive or negative).
Refused or neutral ratings are excluded from this condition as well as from the "Agent rated" trigger.
Additional condition - available for the "Incoming call started" trigger:
To NumberUsing this condition, you are able to fully or partly specify the phone number that should be called (your support number) in order to trigger the rule.
Using this condition, you are able to fully or partly specify the phone number the call should be initiated from (customer's number) in order to trigger the rule.
Additional condition - available for the "Message added" trigger:
Message Group TypeUsing this condition, you are able to define the type of the message that was added (including any system messages as well).
Additional conditions - available for the "Message group added" trigger:
Added By User RoleUsing this condition, you are able to define what should be the role of the action (Apply when) initiator.
Using this condition, you are able to define the type of the message that was added (including any system messages as well).
Additional conditions - available for the "Outbox mail status changed" trigger:
CreatedUsing this condition, you are able to define when should the outbox record be created.
Using this condition, you are able to define when should the outbox record be scheduled.
Using this condition, you are able to define the required status of the outbox record.
Using this condition, you are able to fully or partly define what should or should not be included in the subject of the outbox record.
Using this condition, you are able to fully or partly specify TO recipients of the outbox record.
Using this condition, you are able to fully or partly specify CC recipients of the outbox record.
Using this condition, you are able to fully or partly specify BCC recipients of the outbox record.
Using this condition, you are able to fully or partly specify what should or should not be included in the error response.
Using this condition, you are able to specify the required time of the last send attempt.
Using this condition, you are able to specify the number of send attempts.
Additional conditions - available for the "Queue length changed" trigger:
Tickets Queue LengthUsing this condition, you are able to specify the required queue length for tickets in order to trigger the rule.
Using this condition, you are able to specify the required queue length for calls in order to trigger the rule.
Using this condition, you are able to specify the required queue length for chats in order to trigger the rule.
Using this conditions, you are able to reduce the rule to a specific department only.
Additional conditions - available for the "Ticket created from email" trigger:
Email BodyUsing this condition, you are able to fully or partly specify what should or should not be included this field in order to trigger the rule.
Using this condition, you are able to fully or partly specify what should or should not be included this field in order to trigger the rule.
Using this condition, you are able to fully or partly specify what should or should not be included this field in order to trigger the rule. It is possible to define even exact email addresses.
Using this condition, you are able to fully or partly specify what should or should not be included this field in order to trigger the rule. It is possible to define even exact email addresses.
Using this condition, you are able to fully or partly specify what should or should not be included this field in order to trigger the rule. It is possible to define even exact email addresses.
Using this condition, you are able to fully or partly specify what should or should not be included this field in order to trigger the rule. It is possible to define even exact email addresses.
Using this condition, you are able to fully or partly specify what should or should not be included in any email header code in order to trigger the rule.
Additional condition - available for the "Ticket relation created" trigger:
Relation TypeUsing this condition, you are able to specify the type of relation (ticket mentioned, merged, split) once the relation is created.
Additional conditions - available for the "Ticket status changed" trigger:
New StatusUsing this condition, you are able to specify what should be the new ticket status (status after the last action - answer, transfer, etc...) in order to trigger the rule.
Using this condition, you are able to specify what should be the old ticket status (status before the last action - answer, transfer, etc...) in order to trigger the rule.
Additional condition - available for the "Ticket tags changed" trigger:
Ticket TagUsing this condition, you are able to specify which TAG should be added or removed in order to trigger the rule.
It is not possible to compose an AND statement with the "Ticket Tag" condition (TAG1 added AND TAG2 removed), however, it is possible to compose an OR statement (TAG1 added OR TAG2 removed). Use the "Add condition group" option in order to create an OR statement.
List of rule actions:
Expand ALL
Add Custom Field Value
This action fills your custom customer or contact field with an exact value or any value from the context that matches your regular expression.
It is possible to choose between an exact value (defined on your own right within the rule) or any value from the context that matches your regular expression (defined in the rule).
This actions adds a pre-defined note to a ticket that meets the rule's condition.
It is possible to include also pre-defined attachment.
This action adds TAG/TAGs if the ticket meets the rule's condition.
This action adds/removes the requester (customer) into/from a defined customer group.
It is possible to choose whether to add or remove the customer.
Using this action you are able to affect the execution of futher rules (regardless of the trigger category).
It is possible to choose between multiple types of changes in the executions
This action changes the SLA level of the ticket.
This action increases or decreases the priority of a ticket if the rule's condition is met.
It is possible to choose between several priority levels - The highest priority: 64; The lowest priority: 1/64
This action changes the subject of the ticket to a pre-defined value if the ticket meets rule conditions.
This action deletes the chosen custom field value of the ticket that meets rule conditions.
This action deletes the ticket.
This action sends an pre-defined HTTP request if the ticket meets rule conditions.
It is possible to defined the postback/callback URL, HTTP Method, HTTP Header, HTTP Body, and Encoding. You also able to include available variables.
This action changes the status of ticket to "Answered".
It is possible to add an attachment if needed.
This action changes the status of a ticket from "Spam" to "Open".
This action markes the ticket as spam.
This action merges the ticket with a pre-defined one.
You are able to merger also both tickets' TAGs and/or recipients.
This action adjusts ticket's list of recipients (participants).
Is is possible to add specific TO, CC or BCC recipients, or remove a specific or all TO, CC or BCC recipients.
This action postpones ticket by a pre-defined amount of time.
It is possible choose between default postpone values or define a custom postpone time. Furthermore, you are able to add a note and/or an attachment.
This action purges a ticket (irreversible action) if it meets rule conditions, and prevent from executing other rules for this run.
This action removes a specific TAG.
This action changes the ticket status to "Open".
It is possible to add a note and/or an attachment.
This action changes the ticket status to "Resolved".
It is possible to add a note and/or an attachment.
This action sends an automatic response/answer to the requester of the ticket. In most of the cases, this action is used with the "Ticket created" or "Ticket created from email" trigger. For more details regarding this action, please, visit the following article.
You are able to add an attachment and/or variable, and define the "From name", "Subject" and the "Message" of this response. Furthermore, you are able to compose the response as a simple plain-text email or an advanced HTML-based email.
This action sends an automatic email to any pre-defined recipient (requester, admin, external email, etc...). In most of the cases, this action is used with the "Ticket created" or "Ticket created from email" trigger. For more details regarding the difference between this and the "Send answer" action, please, visit the following article.
You are able to add an attachment and/or variable, and define the "From", "TO", "CC" and "BCC" mail accounts, "Subject" and the email "Body". Furthermore, you are able to compose the body as a simple plain-text email or an advanced HTML-based email.
This action triggers a visual notification.
It is possible to define the list of recipients of this notification, the type of the notification and also the message including variables.
This action is only available with connected slack account and it sends a message to a chosen slack user or channel.
It is possible to include variables in the message.
This action stops further/upcoming rules, but only within the same trigger category. So, for example, if this action is triggered by the "Ticket tags changed", it won't stop other rules with a different trigger, but only upcoming rules within the same trigger.
This action transfers the ticket that meets rule conditions to a pre-defined department and/or assigns the ticket to a pre-defined user (agent, admin, owner).
It is possible to defined a transfer note and/or add an attachment. The "Keep ticket status" option prevents from changing the status to "Open" if needed.
This action changes the status of a ticket from "Deleted" to "Open".
Additional action - available for the "Chat started" trigger:
Add Chat MessageThis action is available only for the "Chat started" trigger and it sends an automatic initial message (just after the "Welcome message" defined directly in the chat button's configuration) once the ringing chat is picked up.
Is possible to include variables and/or attachments.
Additional action - available for the "Incoming call started" trigger:
Change IvrThis action is available only for the "Incoming call started" trigger and it replaces the default IVR ? script with the one defined in this action. Therefore, the default IVR won't be used if the ticket meets rule's condition.
Is possible to define an advanced, full-featured IVR script.
Additional action - available for the "Ticket created from email" trigger:
Forward Email ToThis action is Only available with the "Ticket created from email" trigger and it forwards the ticke to a pre-defined email address.
You are able to choose the mail account that should be used as the forwarder email address.