Every company has its workflow and to set it up correctly UseResponse provides triggers to handle all automation rules managed in Administration » Automation & Notifications.
A trigger is a specific number of actions performed on selected conditions when some event is launched.
Triggers are launched one by one from the top to the bottom, but the logic is that the lower trigger is located - the more priority it would have over the above triggers. In other words - if a higher trigger has specific conditions and lower trigger conditions also match, the actions in both triggers would be combined. But lower triggers would override those actions that contradict a higher trigger in the list. Same logic is applied to actions inside the trigger.
Note: Triggers would work if action is not done intentionally by a support agent. For example, you want to change the status in the interface, but you have a trigger not to change the status. Your intentional action would have higher priority over trigger one.
General Information
Triggers are divided by events, which means that a trigger is launched when some action is performed in UseResponse. There could be several events provided by default to assign a trigger to:
- Object Created - when a topic or ticket is submitted to the system from any available source;
- Comment is Created - when someone replies to the topic or ticket in the system from any source (community, email, social network, etc.);
- The object is Updated - someone changes any field of the ticket or the topic. For example, you can set what field is updated to the specific value and set required actions. One specific about it, is that a condition with "is" means that the object is the following state of the field, but "changed to" means that the field of the object is updated to the selected value;
- User Created - a user is created by a support agent, SSO registered in the system on his own or added from another source;
- User Updated - The user changes his profile or it's changed by a support agent or other source (API, SDK, external 3rd party integration).
There is also a specific event - Scheduled. This event could be used for proactive support and notifications or if you want to perform actions with objects or users after a specific amount of time. For example, send a notification to your customer within 24 hours after the user registration.
Default Triggers
Triggers are mostly used when you need to create a custom workflow for your company, but sometimes the system should work by default the way to notify and subscribe customers and support agents without even going into the automation section. So UseResponse already has invisible default triggers for "object is created" and "comment is created".
By default, the system automatically notifies and subscribes to all support agents in the company and does the same with requesters (authors of topics or tickets). All new users who replied to the topic or ticket would be automatically added to the subscription list to get further notifications.
That's why you don't need to change anything in triggers, to save this logic in UseResponse. Otherwise, you need to create new triggers to override default system behavior.
Setup Triggers & Notifications
To set up a custom rule/trigger, you need to select Event when this trigger should be launched, specify the number of conditions that should "match all" or "match any" of them, and select actions that need to be done if one or more conditions are met. If you want this trigger to be the only one to be launched, change its order to be the highest one and select the option to "Stop on this Rule" for lower triggers are not even checked by the system.
Trigger Priority on Equal Conditions - Different Actions
You can create as many triggers in the system, as you'd like for notification rules of agent teams, etc.
Sample Use Cases
Let's review one of the hundreds of examples using triggers to set up custom workflow. For example, we want to notify only the "Dev" team of support agents when the category "Technical Support" is selected when submitting a ticket. That's how it works:
We should also keep in mind, that in actions you should even specify who should be subscribed to the object, so we add the author of the ticket so he gets further notifications on ticket updates.
Here is the list of some other use cases in that triggers could be used:
- When you want to specify specific assignment or notification actions based on a selected field or field value;
- When you want to change the status or object state based on author details or object fields;
- If you want to trigger actions or notifications after a specific period of time;
- If you want to change object status or state after a specific period;
- When someone replies, you want to change the object state or update the custom field.
- +100 more use cases that you can think of...
As you can see, with the help of automation rules, you can set up almost any reasonable workflow for your company. If we missed any condition or action, please let us know.