Creation Rules in ServiceNow
Anatomy of Creation Rules
Creation rules govern the creation of tasks in ServiceNow. When matched to an alert they will raise a task based on the settings you define in the rule.
Simple properties define the core behavior of every Creation Rule and you will find that you use most of these properties across every Creation Rule you create.
Name - The name of your creation rule.
Ideally, this will give you an idea of what it does at a glance.
Processing Order - Determines the order that creation rules are evaluated.
This is a positive integer with lower numbers indicating a higher priority.
A Creation Rule with a Processing Order of 1 (the highest priority) will be evaluated against an alert before a Creation Rule with a Processing Order of 100.
Once an alert is matched to a Creation Rule no other rules will be evaluated.
Must be unique.
Description - A friendly description of the Creation Rule.
Alert Condition - The condition that an incoming SCOM alert must meet to match against this rule.
Covered in more detail in the next section.
Active - Specifies whether this Creation rule is active or not.
Defaults to false.
Wait Rule - Specifies if this should be a Wait Rule or not.
Covered in more detail here.
Defaults to false.
Creation Rules contain the Alert Condition field which defines the criteria used to match alerts to the rule by their properties. When an alert matches an Alert Condition it is assigned to that Creation Rule. If an alert does not match the Alert Condition, it will be passed on to the Creation Rule next in the processing order until it matches a Creation Rule or no Creation Rules are left to match against.
They use the Standard ServiceNow picker so can be created using logical AND or OR clauses. If using an AND clause all of the selected conditions must be true to match the rule, if using an OR clause any of the selected conditions. They can be used in conjunction with each other to create more complex conditions.
All Creation rules require some sort of criteria to match against an alert. Should you wish every alert to match a particular rule, the usual approach would be to set the filter to 'Alert ID is not empty' as there should be no real alert that fails to match this condition (though does allow you the flexibility to test Creation Rules in isolation).
Available Filter Operators
The following table gives you a rundown of the available operators and gives a basic example of how they could be used in a Creation Rule.
[Alert Name][starts with][SQL]
All alerts in which the characters “SQL“ appear at the beginning of the value for the Alert Name field
[Alert Name][ends with][failure]
All alerts in which the string “failure“ appears at the end of the value for the Alert Name field
[Management Pack Name][contains][SystemCenter]
All alerts in which the string “SystemCenter“ appears anywhere in the Management Pack Name field
does not contain
[Workflow Name][does not contain][Heartbeat]
All alerts in which the string “Heartbeat“ does not appear anywhere in the Workflow Name field
All alerts in which the Severity field says nothing but “Error”
[Resolution State][is not][Closed
All alerts in which the Resolution State is anything but “Closed“
All alerts in which there is no value in the Owner field
is not empty
[Alert ID][is not empty]
All alerts in which there is a value in the Alert ID field
[NetBIOS Name][matches pattern][Infra-*-SQL??]
All alerts in which the NetBIOS Name field matches the pattern “Infra-*-SQL??”.
* matches zero or more of any character.
? matches one of any character.
[Principal Name][matches regex][.*.(domain|DOMAIN).tld]
All alerts in which the Principal Name field matches the regex “.*.(domain|DOMAIN).tld“
All alerts in which the Description field is one of the following:
is one of
[Category][is one of][Alert,StateCollection,PerformanceCollection]
All alerts in which the value of the Category field is one of the following:
is empty string
[Site Name][is empty string]
All alerts in which the value of the Site Name field is an empty string
less than or is
[Resolution State Id][less than or is]
All alerts in which the “Resolution State ID” field is less than or equal to 250
greater than or is
[Repeat Count][greater than or is]
All alerts in which the “Repeat Count” field is greater than or equal to 1
[Resolution State Id][between]and
All alerts in which the “Resolution State Id“ field is between 0 and 254
[Site Name][is same]as[Custom Field 10]
All alerts is which the “Site Name“ field is the same as the “Custom Field 10“ field
[Site Name][is different]to[Custom Field 10]
All alerts in which the “Site Name“ field is different to the “Custom Field 10“ field
All alerts in which the “Time Raised“ field matches the date for today
[Time Resolved][not on][Yesterday]
All alerts in which the “Time Resolved“ field does not match date for yesterday
[Time Raised][before][Last week]
All alerts in which the “Time Raised“ field date is before the date 7 days ago
at or before
[Time Resolved][at or before][This quarter]
All alerts in which the “Time Resolved“ field date is before the date of the start of this quarter
[Time Raised][after][Last 45 minutes]
All alerts in which the “Time Raised“ field is after 45 minutes ago
at or after
[Time Resolved][at or after][Last 15 minutes]
All alerts in which the “Time Resolved“ field is at or after 15 minutes ago
All alerts in which the “Time Raised“ field matches a Monday
All alerts in which the “Time Raised“ field is no more than 22 hours ago
Incident / Task Creation
This section of the Creation rule defines what the rule will raise and the basic properties it will have on creation. The options available will be defined by the type of task raised. A Change Request will naturally have different options and requirements to an Incident.
Record Type - The type of record that you would like to create. Options currently include:
Caller - The caller associated with the created record
Defaults to your service account
Contact Type - The contact type of your created record
Category - The category of your created record
Subcategory - The subcategory of your created record (depends on Category)
Automatically Map CI - If Enabled attempt to match to Configuration Items automatically
Requires our Discovery product
Further information is available here
Configuration Item/Fallback Configuration Item - A statically defined configuration item
When Automatically Map CI is not enabled this will apply to every record created by this rule
When Automatically Map CI is enabled this will apply if a matching CI cannot be found
Impact - The impact level of your created record
Urgency - The urgency level of your created record
Assignment Group - The group that this record will be assigned to
Assigned to - The user that this record will be assigned to
If Assignment Group is set the Assigned to field will scope to members of that group
Company - The company that this record will be assigned to
If using Domain separation this is an easy way of tagging the required domain
These tabs let you heavily customize your Creation Rule. As they are in-depth topics in their own right these advanced topics are covered in the following pages:
Creating Your First Creation Rule
Log in to ServiceNow, search for “Cookdown“ and select 'Creation Rules'
Set a Name
This should be concise but descriptive
Tick the 'Active' checkbox
Set a Processing Order
For example 50
Set an Alert Condition
'Alert Id is not empty' is a great way of selecting all alerts
'Resolution State is not Closed' is a great way of testing filtering
Under ‘Incident / Task Creation’ set the Record Type to 'Incident'
Set an Assignment Group and/or Assigned To value
For testing purposes, we recommend assigning to yourself to minimize any impact
When you are happy submit the rule.
Building up Creation Rules
Typically, you will want to raise tasks against the correct Configuration Item and Assignment Group so that they are handled quickly and effectively by the most appropriate team. This means that you will want a Creation Rule for each set of “like alerts“.
We recommend a rule for each set of unique CI/Assignment Group pairings your company might need and a backstop/fallback rule that creates Tasks/Incidents for triage. Some of our customers have these backstop-created records triaged by a first-line support team while the list of Creation Rules is built out. Others use their SCOM team to triage backstop records as they are often best placed to implement new Creation Rules or tune SCOM. An untuned SCOM environment can generate a large number of unwanted alerts (and therefore Tasks/Incidents) making your SCOM Admins the best placed to prevent the generation of unactionable alerts (have a look at our Easy Tune product which can help with this).
Multiple Creation Rules Example
The result of this example will be a pair of Creation Rules that will create incidents and handle routing them to the correct team. In this example, the SQL Team is a distinct team within IT and needs to handle all SQL-related Incidents. They also want their created Incidents raised against an SQL Configuration Item. All other Incidents are to be routed to a first-line Infrastructure team who tries to fix the most simple issues and triage/re-assign Incidents that they cannot address themselves.
The creation rule for the SQL team is set up with:
Name - SQL Alerts
Active - True
Processing Order - 10
Alert Condition - [Monitoring Object Display Name] [contains] [SQL]
Record Type - Incident
Configuration Item - MSSQLSERVER
Assignment Group - SQL Team
The rest of the properties are left in their default state.
The creation rule for the Infrastructure team is set up with:
Name - Generic Infrastructure
Active - True
Processing Order - 50
Alert Condition - [Alert Id] [Is not empty]
Record Type - Incident
Configuration Item - Infrastructure Services
Assignment Group - Infrastructure Triage Team
The rest of the properties are left in their default state.
Together in the Creation Rules interface these look as follows:
Anatomy of Wait rules
Wait rules are used in conjunction with Creation Rules to introduce a delay between a SCOM alert being received by ServiceNow and an Incident being raised.
Wait Rule Properties
As with standard Incident Creation Rules, a Wait Rule contains criteria that a SCOM alert must hit, which means specific alerts can pass through a single wait rule only.
Wait Rule: Unless this box is checked, the rule is a Creation Rule. Check this box to make the wait rule. Doing this will disable Advanced Creation and Advanced Updates scripting options and remove Configuration Item and Assignment Group options (as they don't apply to wait rules)
Name: the name of the wait rule you are creating
Alert Condition: The condition that an incoming SCOM alert must meet to match this rule. The conditions available are the same as those for Creation Rules.
Wait Duration: How long the SCOM alert should be held before being evaluated against other rules on a lower priority (processing order)
Description: A friendly description of the Wait Rule
Active: Specifies whether this Rule is active or not (default is inactive)
Processing order: The order that this Rule is processed. Lower numbered rules are processed first (IE 1 is the highest priority), an alert can flow through a single wait rule only before hitting a Creation Rule. ServiceNow will not process lower priority rules once it has found a match on a higher priority one.
Next Steps and Further Reading
Your next steps after configuring Creation Rules would normally be to configure an Inbound Notification or Inbound Maintenance Connection. For further reading on the subject of Creation Rules we would recommend: