Every company has its own workflow and to set it up correctly OnsiteSupport 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 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 with a higher trigger in the list.
Note: Triggers would work if action is not done intentionally by a support agent. For example, you want to change status in the interface, but you have trigger not to change status. Your intentional action would have higher priority over triggers one.
General Information
Triggers are divided by events, which means that trigger is launched when some action is performed in OnsiteSupport. There could be a number of 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.);
- 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 condition with "is" means that object is the following state of field, but "changed to" means that 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 - 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 in 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 automation section. So OnsiteSupport already has invisible default triggers for "object is created" and "comment is created".
By default, the system automatically notifies and subscribes all support agents in the company and does the same with requesters (authors of topics or tickets). All new users that replied to the topic or ticket would be automatically added to the subscription list in order to get further notifications.
That's why you don't need to change anything in triggers, in order to save this logic in OnsiteSupport. Otherwise, you need to create new triggers to override default system behavior.
Setup Triggers & Notifications
To set up 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" in order 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 setup 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 that triggers could be used:
- When you want to specify specific assignment or notification actions based on selected field or field value;
- When you want to change status or object state based on author details or object fields;
- If you want to trigger actions or notifications after specific period of time;
- If you want to change object status or state after a specific period of time;
- When someone replies, you want to change object state or update 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.