With the help of dispatcher rules, you can send emails from the system instead of standard notification templates from the Notifications menu:

Why is this necessary? The point is that if you use standard notification templates, you will not be able to achieve the same flexibility that dispatcher rules will allow you to customize. For example, the “email template - new reply” sends a letter to the customer's email when the operator responds in a request. But what if you don't want the email to be sent in all cases, but only in requests of a particular department or status? Or on the contrary, a certain client company has asked not to duplicate replies to their mail at all, as they already track all correspondence through the client portal.

For this purpose, you can create separate rules in the dispatcher and set different conditions under which emails should be sent and under which ones they should not.

After the rule is created and activated, do not forget to disable the corresponding email template in the “Notifications” menu so that emails are not sent twice: because of the enabled template and after the rule is triggered.

Let's consider some of the most popular examples of email templates. To do this, go to the “Dispatcher” menu and first we recommend creating a separate group of rules where future templates will be placed. This is optional, but grouping rules will make working with the Manager much easier, especially as your system grows and the number of rules increases:

1) Now let's create a new rule, which will automatically send to the client a reply to his e-mail that his request is registered in the system. This will be an analog of “Letter template - Request creation from end user' name”:

In the mandatory conditions we specify “New request”, and in the additional conditions you can select different conditions under which the rule should or should not be triggered. In our example, we limit the conditions to the source only - so that the bounce is sent only when the client's e-mail was specified exactly when the request was created. After all, we don't want the rule to be triggered, for example, when a user created a request from Telegram - in this case there would be nowhere to send the email.

In the actions, select “Send email”, and then “To requester”. Below you will be able to select the subject and content of the email.

You can use tags when creating the e-mail and the header, they allow you to get some information about the request in automatic mode (unique number, title, content, dates and other service information). To select tags, click on the icon next to the subject of the e-mail:

Attention! In order for the next responses from the client to come within the same request (and not create new ones), you should specify a tag with the unique id of the request in the header of the email in this format: [#{unique_id}] - as on the screenshot above. The point is that e-mails in the system are “grouped” by the unique id in the subject line. When an operator responds from the system, the client stores the request number in the subject of the email, and when the client responds to this email, the number in the subject remains, and the system, when it receives an email from the client, realizes that it should be “pulled” into a specific request, and not create a new one. If the tag [#{unique_id}] is not in the subject line of an email from a client, then the system will create a new request.  

It is recommended to use this tag in almost every rule in which you send an e-mail.

If you don't know what you want to send in the email content, or are not familiar with html markup, you can simply open a standard notification template, and copy and paste the template from there:

At the end don't forget to save the rule!

2) Rule for sending a letter to a client when a new reply is sent by an employee (analog of “Letter Template - new reply”):

Mandatory condition “new reply in request”, and also do not forget to limit the rule with the additional condition “author of the last response = agent (or assignee), because we need the rule to trigger only when employees respond. If this additional condition will not be present, then the rule will send a letter at a new response from the client, i.e. he will actually receive letters with his own responses, which is not very logical.

Also pay attention to the “+copy (ss)” and “+hidden copy (bcc)” checkboxes. They are responsible for whether the letter should be sent to those participants who are specified in the copy/hidden copy of the letter in the application form. If they are not checked, then the letter will go only to the creator of the application.

Please note that after you enable the rule and disable the standard notification template, the “send letter” checkbox in the application interface will have no effect on anything. Regardless of whether it is clicked or not, the email will be sent, because it is now the dispatcher rule that is responsible for sending it. If the conditions of the rule are met, it will be triggered:

Please note that after you enable the rule and disable the standard notification template, the “send email” checkbox in the application interface will have no effect on anything. Regardless of whether it is clicked or not, the email will be sent, because it is now the dispatcher rule that is responsible for sending it. If the conditions of the rule are met, it will be triggered: