Conditions in dispatcher

Conditions are an important part of the rules in the Dispatcher. Conditions are divided into mandatory and optional conditions. In the Mandatory conditions block you can specify several conditions with “or”, while in the block for additional conditions you can also use “and”. Thus, if a mandatory condition and one of the additional conditions listed with “or” is met, the action will be executed.

The dispatcher does not guarantee instant execution of rules and may be delayed!

Let's take a closer look at what conditions are included in the mandatory conditions:

  • New request - the condition is executed when creating a request;
  • New reply in the request- this condition is executed when writing a reply in the application;
  • New comment in the request - executed when writing a comment in the request;
  • Changes in the request - executed if changes have been made in the request (change of type, status, priority, individual fields, request subject, executor, etc.);
  • Changes in the request creator - performed if the request creator is changed;
  • SLA (request fulfillment period) reached - executed when the SLA time specified in the request has expired;
  • The request is merged;
  • Application unfreezing - executed when the application is unfrozen;
  • Freezing the request until the first response - executed when the request is frozen until the first response (in case the time and date are not specified);
  • Freeze request until date - executed when freezing a request until a certain date;
  • Mention users in reply @ - performed when users are mentioned in replies using the @ + user name (mail) function;
  • Mention users in comments @ - performed when users are mentioned in comments using the @ + user name (mail) function;
  • Added score -  
  • Minutes from last reply - executed when the specified time since the last reply in the request is reached;
  • Minutes from the last comment - runs when the specified time from the last comment in the request is reached;
  • Minutes from the last change - executed when the specified time from the last change in the request is reached.

 

 The “Minutes from last...” conditions have the following features:

 

1) Rules with such conditions are tested in the interval of 1-20 minutes. It means that if the time of the condition is specified, for example, 60 minutes, then the rule, if all mandatory and additional conditions are met, will be triggered between 60-81 minutes.

 

2) The last reply/comment must be made manually by the user - adding and changing these parameters with the help of the dispatcher will not be taken into account by the rule with the “Minutes from last reply/comment” condition.

The same applies to “Minutes from the last change”. Changes to the request must be made by the user (or on behalf of the user) and not by the system. Adding a reply or comment to a request is not considered a change. Changes are changes of statuses, priorities, individual fields, executor, etc. Including API changes counts as a change for the Dispatcher.

 

3) The very first response in the request (i.e. the initial request that created the ticket) is not a trigger for the “minutes from last response” condition, which means that the timer will not be started when the request is created. The condition will be executed only for all subsequent responses.

 

4) In closed (completed) requests the countdown lasts no longer than 3 days (4320 minutes). If you set a longer period of time, the rule will not work in closed requests.

 

5) If a rule or a group of rules with the “minutes from...” condition has been disabled after an event (comment, reply, change) in a request, the rule will not work. Make sure the rule and the group where it resides are enabled, and run the conditions again to restart the timer.

Additional conditions

Request parameters:

  • Event time - executed when triggered within the specified time interval;
  • Time of request creation;
  • Request executor group - executed if the group of the request executor coincides with the specified one;
  • Day of the event - it is executed when triggering on the specified day of the week;
  • Department - the condition is executed if a certain department is (or is not) specified for the request;
  • Time limit reached - it is executed when the allotted time of work with the company is reached, which is specified in the company settings in the system;
  • Request freeze - executed when the request is frozen;
  • Request without sub-request ;
  • The request is a sub-request ;
  • The request is a parent;
  • Executor of the request - the condition is executed if the specified employee becomes (or is not) the owner of the request;
  • Request source - it is executed if the source of the request (where exactly it came from) matches the following: from the system / mail / form or API / chat / social networks or messengers;
  • Request tags - check for the presence of tags in the request. They are specified separated by commas;
  • Request title - check the name of the request for the specified phrase (for example, if the word Urgent is mentioned in the request title, then perform a certain action);
  • Title or content of the request - check the title or content of the request for the specified phrase (e.g. if the word Urgent is mentioned in the request , then perform a certain action);
  • Request grade - check the submitted grade;
  • Request priority - additional filter by the specified priority;
  • Request content - check the content of the request for the specified phrase (for example, if the word Urgent is mentioned in the body of the request , then perform a certain action);
  • Request status - additional filter by the specified status;
  • Status of the request executor - check the status of an employee;
  • TO addressees of the original letter - check to whom the letter was sent. CC/BCC copies are not checked.
  • Request type - filter by request type;
  • Addressees' e-mails - when sending a reply or at the moment of creating a request, the dispatcher makes a check for the correspondence of addressees' e-mails in the “to” field, including ss and bcc (if there are several e-mail addresses).
  • Date and time of the event according to SLA plan - executed if the event occurred during working/non-working hours within the selected SLA plan;
  • Request initiator group - executed if the request initiator group matches the specified one. Not to be confused with the “request creator group” - the initiator is the one who actually created the request, but a completely different user can be specified in the “Client” block (request creator);
  • Adding a label - performed when adding a label in the request;
  • Deleting a label - is performed when deleting a label in a request.

 

Request content:

  • Author of the last comment - if the author of the last comment is the specified: creator of the request, executor of the request, client or employee;
  • Author of the last reply - executed if the author of the last reply is the specified: creator of the request, executor of the request, client or employee;
  • Author's group of the last comment - executed if the author's group of the last comment is the one specified in the condition;
  • Author's group of the last reply - it is executed if the author's group of the last reply is equal to the one specified in the condition;
  • Number of comments;
  • Number of replies;
  • Presence of files in the first reply - checks if there are files in the first reply of the request;
  • Last comment sent - checks the user to whom or from whom the last comment was added: Employee, Partner or From Partner;
  • Content of the last comment - checks the content of the last comment for certain words or phrases (for example, “urgent”);
  • Content of the first comment - checks the content of the first comment for certain words or phrases (e.g. “urgent”);
  • Last reply content - checks the content of the last reply for specific words or phrases (e.g. “urgent”);

 

Request creator:

  • Request creator's group - executed if the group of the request creator matches the specified one;
  • User's company - checks the organization (company) of the request creator (for example, to set the responsible person for a certain company (client));
  • User's full name - check if the user (request creator, client) corresponds to the specified name in the condition;
  • User's e-mail - check if the e-mail of the request creator corresponds to the one specified in the condition;
  • “Name of custom contact field” - check for compliance of the specified information in the custom field of the user's card.

 

Changes in the request:

  • Department change - performed when changing from the specified department to another;
  • Change of an executor - performed when changing from the specified executor to another one;
  • Change of executor by group - performed when changing from the specified group of executor to another specified one;
  • Priority change - executed when changing from the specified priority to another specified priority;
  • Change made - executed when the request creator/executor/customer/employee makes a change in the request.
  • Change of status - performed when changing from the specified status to another one;
  • Type change - performed when changing from the specified type to another one;

 

Individual fields - executed when a custom field value is selected;

 

Change of individual fields - performed when changing the value of a custom field.

© 2025, DaoDesk