Automation rules

On this page

Introduction

In SolarWinds Service Desk (SWSD) automation rules provide a powerful, yet easy way to trigger actions or escalation points, based on parameters of incoming data or comments made within SWSD. With an IFTTT (if this, then that) principle, each automation can be activated and deactivated at any time. SWSD's process automation uses custom rules logic to route, assign, prioritize, and categorize inbound tickets, change requests, and releases.

The automation screen populates as you begin to create automation rules.

Navigation

ITSM customers	ESM customers
Setup > Service Desk > Automation Rules	Service Provider > Service Desk > Automation Rules

Use cases

Change ticket status: When an agent enters a Incident index, the ticket state can automatically update to Awaiting Input. After the Requester responds, the state can automatically update again to Open. See Automation rule to create a change record for more information.
Automate tickets entering the system: When an incident is emailed into SWSD, key words in the text can trigger routing to the appropriate team.
Update priority: Update ticket priority based on impact and urgency custom field combinations.
Apply time-based automations: for more details, see Time-based automations.
Send an alert when an asset is not reporting: Receive an alert and create a ticket when an asset (computer) has not reported via the agent or the scanner within a specified amount of time.
Send an alert when an asset changes status: Receive an alert, update the record, and create a ticket based on an asset's (computer's) change in status.

Components of an automated rule

Review the list of components for creating automation rules and begin exploring with rules relevant to your organization.

Trigger

Creating automation rules begins with defining your trigger. What is the catalyst that prompts an automation rule to run? Consider what actions could be automated to help streamline processes.

Be aware that one automation rule cannot trigger another automation rule. Automation rules run sequentially. Rules look only at the original data in the object when the automation is triggered. For example, if you have a series of rules that are triggered when a new ticket is created, and Rule 1 changes the state of the ticket to Updated, Rule 3 in the series cannot match to the new ticket state because it is still looking at the original state: New.

Available triggers include:

Object created. Automation is triggered when a new incident, service request, or change request is created.
Comment added. Automation is triggered when a new comment is added to an incident or service request, or a note is added to a change.

The first comment on an incident pauses the SLA clock and is registered as a first response.
Object updated. Automation is triggered when a field is updated. In Conditions you can select Any change or define the specific field that must change for the action to be triggered.
Custom. The custom trigger lets you optimize your automation rules by combining all three triggers (object created, a comment is added, or an object is updated) into one rule.

Scope

The scope narrows which object the trigger will apply to. You can select from the dropdown menu:

Incident/Service Request
Change
Asset (computers only)

Conditions

After your trigger has been defined, you can move to establish your parameters through conditions. The condition parameters define what SWSD will check for a match. The type of condition defines when SWSD will check for a match.

There are two types of conditions: regular and time based. A regular condition performs a check immediately after a trigger occurs, while a time-based condition may decide to reschedule a check to a future point in time. (See Time-based automations for more information.)

Conditions can range from specific keywords to custom fields or attributes (like priority, state, etc.) among others. All text fields (name, description, and text based custom fields—including dropdown fields) are checked with the keyword condition.

When adding additional layers to your parameters, you can add multiple conditions. When creating a condition, you select the:

Value type (any change, current value, value updated from, or value updated to)
Field (the field that must be changed for the action to be triggered)
Value (the value related to the value type). Not required when value type is Any change.

You can define the operators between conditions as:

All the conditions (default selection). All conditions must be met for an action to be triggered.
Any condition. Any single condition must be met for an action to be triggered.
Custom. After building the conditions, you can then specify which must be met for an action to be triggered.

When you create a condition, SWSD assigns it a condition number. You can then use the condition numbers to customize which must be met for an action to be triggered.

When you have multiple conditions, you can streamline processes by selecting the specific condition type needed for the process. For example, by customizing the Operator between conditions you can select 1 (and 2 or 3) or any combination necessary.

Actions

The action(s) behind your automations are initiated when the defined conditions are met. You can take actions such as altering the priority, reassigning ownership, relaying notifications, and updating/appending a record using the CC field. There is no limit to the number of actions within a rule.

Example

Reminder notifications: Using a time-based condition you could remind a technician or team that a requester submitted a Incident index one day (or more) ago.

Click Save to update the new information entered.

Regular expressions (or regex) within an automation

A regular expression (also known as regex) is a unique text string that defines a search pattern. Regex is a programming language that allows for advanced searching within texts. You may be familiar with wildcard notions such as *.txt, which helps you locate all text files in a file manager

The regex equivalent to *.txt is ^.*\.txt$.

The difference may not look substantial, but it is much more powerful than a simple wildcard. Even if you are not a regex expert, you can take advantage of regex in your SWSD. After you understand a few basic elements, you can create keyword searches that go beyond a single keyword.

Regex breakdown

Regular expressions are a useful way to extend the functionality of the keyword condition in automations. You can include:

multiple keywords
a variety of spellings
uppercase vs. lowercase letters, and more

Best practices for using regex

To adjust for capitalization, create a regex to allow for uppercase and lowercase letters to be considered valid by the system. To do this, you must follow the syntax:

[kK]eyword or [eE]xample

The first letter is shown in brackets in both lowercase and uppercase format. This will allow for both: keyword, and Keyword to be recognized.
To use multiple keywords within one condition, create a regex list using the following syntax:(keyword|example|list|complete.

The | works as an OR in this list. In this example, any one (or more) of the following keywords would trigger the action associated with the automation: keyword, example, list, or comp
To use multiple keywords within one condition, create a regex list using the following syntax:

(keyword|example|list|complete)

The | works as an OR in this list. In this example, any one (or more) of the following keywords would trigger the action associated with the automation: keyword, example, list, or complete.
To combine best practices 1 & 2, make use of a list with both uppercase and lowercase letters -

(urgent|critical|[hH]elp\s[pP]lease|serious)

This would let the following words be triggers for the automation: urgent, critical, help please, Help Please, help Please, Help please and serious. The addition of the \s in the keyword ‘Help Please’. That \s is the regex code for a space. If the keyword you are looking for has a space in it, you must use \s in place of the space.
To adjust for incorrect, or alternate spellings of words, use the same syntax used for uppercase and lowercase letters. For example, if you wanted to account for a commonly misspelled word such as “consensus” you could use the following:

con[sc]ens[ue]s

This would recognize the following words as the keyword, and thus trigger the action you set for this automation:
- consensus
- concensus
- consenses
- concenses
Placing letters inside the brackets [ ] allows for regex to recognize either letter as an option within that keyword. This can be very helpful when dealing with commonly misspelled words.

Internet tutorials and resources

A quick search of the internet can provide links to regex tutorials and expressions. For example, see regex101.com.

Automation rules index page

The automation rules index page displays all of your automation rules on one page. You can add filters and columns to customize your view. See List view for guidance on customizing.

Change the order of automation rules

From the automation rules index page you can reorder rules from the automation rules index page two ways.

You can click the number of a rule in the first column and change that number.
You can hover to the left of the first column and select the row by clicking the six dots icon. The cursor changes to a hand so you can drag and drop the rule to change the order.

Create a new automation rule

Enterprise Service Management (ESM) service providers can create their own service-provider specific automation rules.

From the Automation Rules index page, click Add .
In the Add Automation Rule dialog, select the appropriate trigger and scope from the dropdown lists.
Determine whether your rule will use a single condition or multiple conditions. For multiples, decide whether to use the default All the conditions operator, the Any condition operator, or the Custom operator for more complex scenarios.

Be careful with your use of the All the conditions operator. Ensure that the conditions you are creating could all occur from the trigger.
Determine whether you will use time-based conditions for your automated actions to take place.
- If yes, see Time-based automations.
- If no, proceed.
Click + Add Condition .
In the New Condition dialog, select the field and value, and then click Add Condition.

Each field has its own list of available values.
Click + Add Action .
Select an action from the dropdown list. Options are Add tag, Create record, Send notification, and Update record.

Before selecting the Update record option, see Using the Update record workflow action.
Optionally, you can add variables to the Title and Description fields. To the right under those fields you can click Add Variables to see a list of variables you can use.
Populate the appropriate fields of the selected option, including the optional Description field.

You can click + Add Action again to add more actions.
Notice the default setting in the upper right corner of the new automation rule is Active.
Click Save at the bottom when finished.

Example for Incident/Service Request scope

You can see below that the Trigger is Object updated. In this example, if the current value for Site on the ticket is Shelby and the value for Category on the ticket is updated to Hardware, the automation rule will reassign the ticket to Janet Perez.

Deactivate an automation rule

Navigate to Setup > Service Desk > Automation Rules.
Click the automation rule you wish to deactivate.
In the Automation Rule dialog, change the toggle from Active to Inactive.
Click Save.

Instructions for specific use case automation rules

You can use the following guidance for specific use cases of automation rules.

Search SolarWinds Support