List of conditions and actions in the triggers

Conditions and actions that you can use when creating triggers:

Block «When»

  • Always — there is a reaction to any action in a query;
  • A client wrote a message/An agent wrote an answer/An agent wrote a comment — the trigger will respond to a certain type of message in a ticket;
  • The Bot wrote a response — reaction to a previous bot-message: all automatic messages and notifications that are configured by the triggers are sent on behalf of the company bot (for more details, click here);
  • A ticket has been changed (any/status/priority/type/tag/contractor/channel/ SLA policy/custom field) — response to change of one of the ticket parameters. For example: when selecting «Any» — the trigger responds to any changes, «Ticket field» — when changing the value of one of the custom fields;
  • A ticket reopened with a reminder — read about reminders in this article;
  • A trigger has changed a request — the current trigger will react after another trigger has already worked on the ticket;
  • A ticket creation date/The last ticket update/The last agent message/The last customer message — the trigger is valid if one of these events occurred at a specific moment or period (see below for more details about options);
  • Time until the next SLA violation/Time since the last SLA violation — the trigger works when there is a certain time left until the deadline for response/after the deadline for response, which you set yourself.

    The «(work hours) less/greater» time setting counts only working hours — according to a company schedule, specified in the settings. It excludes night hours and lunch breaks. For example, if a trigger is configured to work 24 working hours before a SLA expires and a twelve-hour working day without a lunch, then it will work not exactly one day, but two days before a SLA expires: two days of 12-hour workdays without taking into account nighttime breaks. The «(calendar) less/greater» time setting, on the contrary, counts all the time, not taking into account a company work schedule. If a SLA expires tomorrow at 6 p.m., and a trigger is configured to work 24 hours before a deadline, today it will work and execute the specified actions in the next minutes after 6 p. m.;

In some time conditions, there are additional parameters.

Note! The period of time in the field must be specified in the format 2d 5h 30m 2s, 5h 30m, 2d, etc.

The conditions, which are based on a specific date:

  • time has passed / time has not passed — specify the period since the event;
  • a date equals/date earlier than/a date is later than — select a date from the drop-down calendar;
  • period of time — enter a specific period within a day in the format <h:mm -="" h:mm="">;</h:mm>
  • working time (company) — indicate that the event occurred during working or non-working hours of the office, specified in the settings;
  • working time (group) — indicate that the event occurred during working or non-working hours of the agent group. A trigger with this condition can only work if an executor has already been assigned to a ticket at the time a trigger worked. If a ticket is not assigned to any group, a trigger will not work.

Conditions that consider the period before or after the event:

  • (calendar) less/greater — the trigger starts when less/greater time is leftover or has passed;
  • (work hours) less/greater — the same, but only the office hours specified in the company settings are taken into account.

Block «What»
In this block you can work with the standard parameters of the ticket and client:
  • Client name;
  • Client email — this condition checks all email addresses for communication with the client, which are specified in his card;
  • Client contact — this condition responds only to the current email address of the client with whom the dialog is conducted;
  • Client type;
  • Client language — the condition responds to the «Language» field in the client profile. With this parameter, for example, you can set up a trigger that will send an auto-response in the language a client uses to communicate;
  • Channel;
  • Status;
  • Assignee;
  • Assignee status (online/offline) — in ticket or chat form;
  • Agent status (online/offline) — in the ticket or chat on a specific employee or group of employees;
  • Subject;
  • Tag;
  • Company;
  • Priority.
Note separately what these parameters mean:
  • Client note — what text does/does not contain the note in the client block (in a ticket);
  • Message — which text contains/does not contain a message/comment in a ticket (for example, it is convenient to configure this field for emotionally colored words that allow you to calculate acute cases and quickly deal with them). In the additional condition you can choose, which messages the rule should respond to;
  • Message source code — this condition looks at the source code of the message. Use «text contains regexp» for this condition;
  • E-mail copy — the condition checks the «Copy» and «BCC» request fields of the last public message;
  • Attachments — whether there are attached files in the ticket;
  • CSI rating — whether the client has assessed the support work on his question;
  • CSI comment — has the client added a comment to its support rating;
  • CSI сomment text — which text contains/not a CSI Rating comment;
  • Groups — which group of agents an agent belongs to;
  • SLA policy — which SLA policy applies to the ticket;
  • Messages from a client — a number of messages a client wrote in a specified time;
  • Tickets from a client — a number of tickets a client created in a specified time;
  • Last message from — the system will check from whom the last external message in a ticket came: from the client, agent or bot;
  • Reminder — the system checks whether the reminder is set or not;
  • Ticket field — the value specified in the custom field.

«Do» block
In this block, write down what the trigger should do when it finds a ticket that suits your conditions:
  • Update a type/priority/status/assignee/subject — change the parameter from the current one to another;
  • Update a client — change the client specified in the current ticket;
  • Send a message/Create private comment — send the text to a client or colleagues;
  • Add tags/Delete tags — after entering a tag, be sure to press space to write a tag;
  • Send a message to an agent — write a text that will be sent to a colleague in the system (or to Usedesk, if his mail is connected to Usedesk as a separate channel) as a notification about a ticket or event;
  • Send an email — send a message to any external email;
  • GET request/POST request — specify a script to exchange data with the external system. GET and POST requests can be used to set up notifications in Telegram and Slack. Please follow the link in our documentation to read more details about making GET and POST tickets;
  • Update a company — add or change the company that the client represents to his profile;
  • Assign to a least busy agent — assign the number of requests in the «Opened» and «New» statuses to a user, which has less requests than other users. If a trigger is set up for a chat only, then Usedesk takes into account the number of tickets in a chat only, and if a trigger is set up for requests, it takes into account the number of requests in a chat + ticket. An action will be executed only if agents in their group settings have access to work in a channel, where a ticket is;
  • Assign to a least busy agent (online) — similar to the previous parameter, but the choice will be made only from agents in the online status at the moment the trigger is active. An action will be executed only if agents in their group settings have access to work in a channel, where a ticket is;
  • Assign to a next agent — assign ticket in order regardless of agent load (technically, by the list of agents id), the list or group of which should be specified in the field to the right. An action will be executed only if agents in their group settings have access to work in a channel, where a ticket is.

    If one agent belongs to two or more groups specified in the action, the assignment will occur only once;
  • Assign to a next agent (online) — similar to the previous parameter, but the choice will be made only from actors in online status at the moment the trigger is active. When distributing a trigger to the next agent online, the system selects an agent who is online in the same section (chat/tickets).

    An action will be executed only if agents in their group settings have access to work in a channel, where a ticket is;
  • Change SLA level — apply a different SLA policy if the system has several policies for different agents or situations. More information about SLA policies can be found here;
  • Ticket field — if you have custom fields in your company account, the value of each of them can be changed by a trigger: all additional fields will automatically appear in the list of actions in the format <name of="" additional="" field="">(request field);</name>;
  • Add client to the Blacklist/VIP — when a client is marked as VIP, its mail is added to the white list and removed from the blacklist. If the client is flagged as spammer, their mail is added to the blacklist (not deleted from the white list). The client's tickets are given the status of «spam»;
  • Change channel — helps to distribute calls to different channels if the main thread comes to one (if there is a change in a rule to a channel type the client has more than one — the very first one is used, i.e. if there are two mails, the very first is used). For a successful channel change, an email should be specified in a client card.

Under block conditions, you will see the following options:

  • Equal/Not equal — specify a value from the proposed list (statuses, channels, executors, etc.): the trigger starts if this value is relevant or, on the contrary, is not relevant to the ticket;
  • Yes/No – specify a needed value: a trigger will launch if this value is relevant or, conversely, not relevant to a ticket;
  • Changed from/Changed to/Not changed from/Not changed to — you can set a trigger for such cases when parameters in a ticket change, or, on the contrary, remain constant. For example, one of your triggers changes assignees from a marketing group to a sales group, and in another you want to take into account only those tickets in which there was no such a change of assignees;
  • Text includes/excludes — the rule will be triggered if the ticket parameter (in the subject of the e-mail) contains/disables the text that you specify in the next field;
  • Text equals/Text not equals — the rule will be triggered if a ticket parameter (e.g. client name) exactly matches/is not the same as the one you specify in the adjacent field;
  • Text starts with/Text ends — this is convenient to use for typical messages which start or end with the same words, numbers, phrases;
  • Data entry — specify a regexp — HTML-code, which helps to select specific data (e-mail or phone number) from the text of the letter;
  • In a ticket/In a chat/ In tickets (Online)/ In tickets (Offline)/ In chats (Online)/ In chats (Offline) — specify a needed value so that a trigger reacts only to a needed agent/assignee presence statuses in chats/tickets;
  • First/First (agent)/ First (client)/ First internal comment/Last/Last (agent)/ Last (client)/ Last internal comment — specify a needed value so that a trigger reacts only to relevant agent/client messages;
  • First comment/Any comment — specify a needed value so that a trigger reacts only to certain comments;
  • Agent/Client/Bot — specify a needed value so that a trigger reacts to messages only from a person with a specified role.