On this page
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.
The automation screen populates as you begin to create automation rules.
Setup > Service Desk > Automation Rules.
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 SolarWinds Service Desk 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.
Review the list of components for creating automation rules and begin exploring with rules relevant to your organization.
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. 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.
Object updated. The automation is triggered when a field is updated.
Custom. The custom trigger allows you to optimize your automation rules by combining all three triggers (object created, Incident index table added, and object updated) into one rule.
The scope narrows which object the trigger will apply to. You can select from the dropdown menu:
- Incident/Service Request
- Asset (only computers at this time)
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.
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.
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.
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
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.
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:
[eE]xampleThe 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 -
This would allow for the following words to 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:
This would recognize the following words as the keyword, and thus trigger the action you set for this automation:
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.
Go to Setup > Service Desk > Automation Rules.
From the Automation Rules index page, click Add .
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.
Determine whether you will use time-based conditions to 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 Send Notification, Update record, Create record, and Add tag.Before selecting the Update record option, see Using the Update record workflow action.
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.
Workflows allow your organization to 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 allows the workflow creator to 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.
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
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.