Building Automations
Applications
Applications represent different products within the Capacity platform. Most automations will likely fall under the Helpdesk application, but there are also options for Analytics based events (i.e. webhooks) and CoreAPI (file upload).
- Helpdesk - Automations related to Helpdesk events
- Ticket creation, ticket update, SLAs, etc.
- Analytics - Custom triggered events. Similar to “webhooks” for those familiar
- CoreApi - File upload automations
Triggers
Triggers are the “event” that causes an automation to “run”. Each trigger comes with a list of conditions which can be used to limit when the automation should be run. Some conditions are available to all triggers, some conditions are only available for specific triggers/applications.
In addition to the condition values, some “modifiers” are also unique to specific triggers. When creating an automation, be sure to select the correct trigger so you can have access to the right conditions and modifiers that you need to correctly define when the automation should run.
Triggers
Below is a list of each trigger, and the application to which they belong.
| Application | Trigger | Description |
| Helpdesk | Ticket created | Runs when a ticket is created |
| Helpdesk | Ticket updated | Runs when a ticket is updated |
| Helpdesk | Ticket time interval | Runs every hour for each ticket |
| Helpdesk | Ticket SLA breached | Runs when a defined SLA is breached |
| Helpdesk | Ticket SLA breached goal | Runs when a defined SLA goal is breached |
| Helpdesk | Correspondence created | Runs when an “email” is added to the TO or CC field of the Helpdesk ticket reply list. |
| Helpdesk | Interaction created | Runs when a reply is received or sent from a ticket, or when a comment is created |
| Helpdesk | Email Created | Runs when an email is created, similar to interaction created, but limited to emails |
| CoreAPI | File Updated | Runs when a file is updated or created |
| Analytics | Analytics Event Created | Runs when an analytics event is fired via external means |
| Concierge | Concierge Event | Runs when a Concierge event is fired by browsing or Concierge bot interaction. |
| Concierge | Concierge Time Interval | Runs on time intervals when a user is engaged with a Cconcierge. |
Conditions
Conditions are comparison statements made up of:
- The initial field to compare
- A modifier or operator used in the comparison
- The comparison value.
These three parts combine to create the “condition” that will limit when your automation runs.
The conditions available to use will be determined by the trigger selected. Some conditions are unique to the trigger selected for your automation. For example, in the Helpdesk application, selecting the “interaction created” trigger will provide conditions like “reply received”, which provides a true/false value for if the interaction was an external reply, or a reply from an agent.
Example
Pretend you have an automation that is set to send a notification email when a ticket is created. You might want to add a “condition” to only send that notification email for tickets created in a specific project. You would set the condition to “project, equals, project name”. Conditions like this allow you to get specific when defining the situations in which your automation should run.
It’s common when creating an automation to start broad and then narrow down with conditions while testing. For example, you might start with an automation that reopens closed tickets when the ticket receives a reply from the reporter. After turning it on, you then realize you don’t want to reopen the ticket if the reporter happens to be an agent, so you add a condition to the automation to only run if the “user’s email, does not contain, your agent domain name”.
Learning which condition to use and when can often require some trial and error, but the result is well worth the effort. Capacity is continuing to grow our list of commonly used automations which we add to our automation defaults and templates so you can use them with one click.
Modifiers and Operators
Modifiers and operators are the second dropdown in an automation condition used to define how you compare your condition values. Not all modifiers and operators are available for all triggers or fields. The dropdown field changes dynamically based on the previously selected field.
One commonly used example is the “changed to” or “changed from” modifier, which is only available for some fields in the “ticket updated” trigger. This special modifier allows you to compare the value the field was “changed to” or “changed from”. For example, you might create a condition to only run an automation when the ticket status was changed from “To do” to “In progress”.
Grouping Conditions
Conditions can be combined and grouped to create complex checks before running an automation. Conditions can be added one after another to create “AND” checks, or they can be put in “groups” to create “OR” checks.
When conditions are added using the AND operator, all conditions must be met for the automation to run. When conditions are added using the “group” option, you will see an “OR IF” operator. Each “group” of conditions is a group of AND conditions. Between each group is an OR operator. Combining the use of AND and OR IF, you can create complicated combinations of conditions for your automation.
The example conditions below checks if “Project name is HR, AND the ticket status changed to Done” or if “Project name equals Articles, AND the ticket status name is changed to Approved”
Actions
The final step in an automation is defining the actions to take when the automation triggers and conditions are met. Some actions are unique to specific applications and triggers. Actions include:
- Send an email
- Start a Workflow
- Update a ticket (unique to Helpdesk application)
- Launch a Conversation
- Ask a Concierge (NLP)
- Open Bot
- Open Bot In Full Screen
While the action list may seem small, in reality being able to launch a Workflow opens up a whole world of powerful automation options. Workflows can be used with Capacity Apps to do just about anything, from updating tickets, to communicating with other applications, to launching conversations in an active concierge. Combining automations with workflows makes it possible to automate almost any process.
Action variables
Much like Guided Conversations and Workflows, “variables” can be used to pass information to your automation action. When clicking into an action field, you will see the familiar lightning symbol indicating variables can be used for the value in the field.
Selecting a variable from the dropdown list will add it to the field where it will be replaced with the associated value when the action runs.
You may notice that the variables available seem very similar to condition options. Similar to conditions, the variables available will change depending on the Application and Trigger selected. Variables can be used in the action field to pass values to Workflows or use in emails being sent.
Sometimes it can be difficult to know what variable is actually being passed. We recommend testing your automation and reviewing the variables with a “Send an email” action before adding the final action you want the automation to take. This will allow you to check that your automation works under the correct conditions and review the variables you want to use in your action.