Documentation forSolarWinds Service Desk

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 table, 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.

The available triggers include:

  • Object created. This trigger hones in on the creation of a new incident, service request, or change in your service desk.

  • Comment added. The automation is triggered by the addition of a new Incident index table to an incident, service request, or note on a change.

    The first comment on an incident pauses the SLA clock and is registered as a first response.
  • Object updated. The automation is triggered when a field is updated.

  • Custom. The custom trigger lets you optimize your automation rules by combining all three triggers (object created, Incident index table added, and object 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 (only computers at this time)

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, 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, your operators between conditions can be AND/OR.

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 table 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.

Create a new automation rule

Enterprise Service Management (ESM) service providers can create their own service-provider specific automation rules.
  1. From the Automation Rules index page, click Add .

  2. In the Automation Rule dialog, select the appropriate trigger and scope from the dropdown lists.

  3. Determine whether your rule will use a single condition or multiple conditions. If multiples, decide whether to use the default OR operator or the AND operator.

    Be careful with your use of the AND operator. Ensure that the conditions you are creating could all occur from the trigger.
  4. Determine whether you will use time-based conditions for your automated actions to take place.

  5. Click + Add Condition .

  6. In the New Condition dialog, select the field and value, and then click Add Condition.

    Each field has its own list of available values.
  7. Click + Add Action .

  8. 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.
  9. 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.

  10. Populate the appropriate fields of the selected option, including the optional Description field.

    You can click + Add Action again to add more actions.
  11. Notice the default setting in the upper right corner of the new automation rule is Active.

  12. 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.

Using the Update record workflow action

Workflows let your organization automate processes. As a process develops, there is often a need to update the request record with a new state or additional information. The Update Record action lets the workflow creator update multiple fields, including most system fields and custom fields.

Default value for State field

By default, when a workflow reaches its end, the value of the request’s State field is automatically set to Resolved.

If your organization intends to use the Update Record action in workflows, SolarWinds recommends that an administrator change the default behavior to leave the State field unchanged. An admin can do this by navigating to Setup > Global Settings > Service Desk and disabling the toggle for Auto set state to resolved at workflow completion.

When the pill is in the On position (default setting), incidents and requests are updated to a Resolved state once the workflow process is complete, regardless of  how it completed. That is, even if the process failed or was not approved, the State changes to a Resolved state.

When you toggle the pill to the Off position, the state remains intact and you can change the State inside a workflow without having it reset again at workflow completion. Note that this setting is global and affects the behavior of all workflows.

Preserving the State value at workflow completion can help with a number of scenarios. For example:

  • Indicating the success or failure of a workflow/process.
  • Reflecting progress inside long/complex workflows.
  • Flagging specific errors that were detected during workflow execution.

Deactivate an automation rule

  1. Navigate to Setup > Service Desk > Automation Rules.

  2. Click the automation rule you wish to deactivate.

  3. In the Automation Rule dialog, change the toggle from Active to Inactive.

  4. Click Save.

Instructions for specific use case automation rules

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

Related topics