HelpSpot Automation Explained

Over the last decade of developing HelpSpot, we’ve added a number of ways to automate the system. Automation lets you work faster, get the right tickets to the right people at the right time, and can remove some of the manual aspects of working customer support. The three main automation tools in HelpSpot are Triggers, Automation Rules, and Mail Rules. Each has a unique purpose and some special abilities. You’ll find all 3 in your HelpSpot installation under Admin -> Triggers & Rules. This is a fairly in depth article, but for those of you who just want the quick summary, I’ll start with that.

Mail Rules

• Only work on email
• Only work on new requests
• Real time

Triggers

• Real time
• Can watch for changes between field states
• Can only act when a change occurs, can’t actively search for changes

Automation Rules

• Run on a schedule
• Query the HelpSpot database to match conditions making them useful for time-based searching
• Run outside of the HelpSpot interface so they don’t impact performance
• Ideal for SLAs, escalations, and batch processing

Now, onto the details!

Mail Rules

We’ll start with the simplest automation method first. Mail Rules are very much like the mail rules you’ll find in any email client such as Outlook or Apple Mail, and are a simple way to work with inbound email. The first thing to know about Mail Rules is that they are only applied on new requests, not updates to existing requests. So if you need to do something with updates on existing requests, you’ll want to use a Trigger instead (more on them below). Mail Rules are unique in that the conditions you can set for matching emails are specific to email, whereas Triggers and Automation Rules work on general HelpSpot request values. For example, in Mail Rules you can search the CC field of an email and cause an action to happen based on the CC fields value. You can also search the TO and From fields, body of the email, whether it has attachments, and more. One thing to note is that when you’re searching an email header such as the TO field, you’re searching the entire header. This is why HelpSpot defaults to ‘contains’ vs. an ‘is’ style matching. A full TO email header looks like this: “` “Ian Landsman”

“` Normally you’ll end up using something like, “TO ‘contains’ ianlandsman@example.com.” An ‘is’ match, in contrast, would require it to be exactly like the full line above which is usually not what you want. Another useful attribute of Mail Rules is that they appear in real time. They work directly as the emails enter the system (Triggers can work the same way) so any data they change, such as setting a category, is instantly available in your filtered views.

When to use a Mail Rule

The first consideration as mentioned above is that you can only use mail rules when the automation you want to perform is on new, inbound email. Any other scenarios need to be covered by Triggers or Automation Rules. Mail Rules are often used for routing in email-heavy installations. For example, you may create a rule that when an email comes in containing the phrase “pizza the hut” then Mail Rules assigns the email to Bob. The same principle could be applied to replying to customers instantly. When an email matches a set of criteria, you could send back an “instant reply” action, which emails the customer a first pass at a solution, such as linking to specific knowledge book articles. Mail Rules are also a great way to handle VIP users. Perhaps you want to assign all emails that come in from a particularly important email account or email domain to a certain person, status type, or category. All are easily possible with Mail Rules.

How Mail Rules Differ from Triggers and Automation Rules

Most of the use cases above can also be done with Triggers and Automation Rules, so the primary consideration when choosing to use a Mail Rule is whether you need to search email headers like TO, From, Subject, etc. in your routing. One other lesser factors is that Mail Rules are somewhat faster than Triggers, the other method of handling real-time automatic triaging of new requests. Therefore, in situations with larger installations involving dozens or even hundreds of these kind of rules, it is quicker to use a Mail Rule than with many Triggers.

Key Features

• The work in real time
• The only automation type that can search email headers like TO, From, Subject, etc.
• Useful for instantly routing or replying to requests

Limitations

• Only work on new inbound emails, not emails updating an existing request or requests created via the portal or API

Triggers

Triggers run in real time, watching your installation and acting on changes. Triggers are perfect for scenarios where you want to instantly react to a situation. There are two types of Triggers, ‘create’ and ‘update’. ‘Create’ Triggers only act on newly created requests and ‘update’ Triggers watch existing requests for changes. The distinction allows you to create different flows for different situations. Triggers are unique in that they can detect state changes on fields. For example, you can define a Trigger to watch for the changing of one category to another as seen below: “` Category ‘changed from’ Support Category ‘changed to’ Sales “` In this case, when a request is updated, changing its category from Support to Sales, we can allow a series of actions occur. Perhaps we assign the request to a particular staff member or notify the sales manager (or both). Triggers can also disregard the state information and simply work off of what is currently the value of the field using the ‘now is’ check. “` Category ‘now is’ Sales “` With this condition, the Trigger will match and its actions be performed regardless of which category the request is currently in or even if that field hasn’t changed at all. Triggers can work with many system fields, as well as custom fields, allowing for a nearly limitless combination of conditions. Triggers also have access to several advanced actions (as do Automation Rules). These actions include the automatic running of Live Lookup, initiating a Request Push, and calling a Webhook (new in version 4). These advanced actions give you some really powerful tools. For example, use a ‘create’ trigger to run Live Lookup on every new request that comes in. By doing this, Live Lookup can set all the customers information, set custom fields, and have everything ready to go so the request is properly filtered and no manual button clicking is required by staff. Using Request Push or Webhooks, Triggers can be used to integrate HelpSpot with your own data systems. Post a Webhook to your server every time a new request comes in and use that data to update your CRM to create a cross reference between sales and support.

How Triggers differ from Mail Rules and Automation Rules

Unlike Automation Rules, Triggers work in real time, which is key for certain types of automations. However, this can also be a limiting factor in other cases (more on that in the Automation Rule section). Triggers work on all requests no matter how they are created or updated. This distinguishes them from Mail Rules. The fact that Triggers run in real time means that some consideration about system performance is required. With ‘Update’ Triggers, the Trigger will run (to check its conditions) on every single update of every request. So you generally don’t want dozens or hundreds of those. However, we don’t set any hard limits about quantity, as the maximum is very dependent on how many requests you handle and your server resources.

Key Features

• Work in real time
• Watch for transitions between field values/states
• Watch for changes on creation or updating of requests
• Have access to many actions including advanced integration actions

Limitations

• Only react to changes, they can’t look for events that haven’t happened as Automation Rules can
• ‘Update’ Triggers run in real time while you update requests, so some consideration of system performance needs to be given

Automation Rules

Automation Rules are unique because they run on a schedule. Your server will run the rules at least once a day, though you can customize the schedule for all rules together or even on a per-rule basis (see tasks2.php explained for details). Because the rules are scheduled, they can do things that neither Mail Rules nor Triggers can. Automation Rules can look for the lack of something, which is often critical for a help desk. For example, Automation Rules are great for creating escalations. You can create a rule that runs every minute and continuously checks for a scenario, which would warrant escalating a request. One common reason to use this type of Automation Rule is to escalate a request that has been unanswered for too long. There are countless conditions we can use to isolate any scenario you may need, but here is a simple example: “` Open/Closed ‘is’ Open Minutes since last public update ‘is greater than’ 240 “` Here, if a request is open and it has been more than 4 hours since the last update, we can escalate it to level 2, alert a manager, or take whatever action we’d like. Here we’re searching for something that has not occurred (an update). This is something neither Triggers nor Mail Rules can do. This ability is very useful for SLA management, escalations, notifications, and more. Automation Rules can also be used in ways similar to as to our previously mentioned scenarios—creating instant replies to customers (nearly instant as the rules will run at most every minute), running Live Lookup, Request Pushes, and Webhooks. Automation Rules can also be used for batch operations. Perhaps you need to update a field across many requests or send a survey to many previous requests from a particular timespan. All of these actions are easily accomplished with Automation Rules.

How Automation Rules differ from Mail Rules and Triggers

The key difference is that Automation Rules run on a schedule, which allows them to query the HelpSpot database looking for conditions instead of waiting for an action to happen in real time. Automation Rules also run outside the context of updates to requests (since they are not real time). Therefore, even very complicated rules with many conditions and actions won’t hurt system performance. Automation Rules tend to focus on time-based events such as the time since a last update or time since a customer update. This, in combination with other conditions covering nearly every field or custom field in HelpSpot, allows for very flexible usage across a variety of scenarios.

Key Features

• Work on a scheduled interval, not real time
• Query the database for conditions, which makes looking for time based conditions possible
• Run outside of request updates so they don’t impact system performance.
• Have access to many actions including advanced integration actions

Limitations

• A schedule must be set on the server (via Cron or Windows Scheduler)
• Are not real time so there can be a slight delay when using Automation Rules for Live Lookup or other field setting scenarios.