Creation Rules

For versions prior to v2.0.0 please see Incident Creation Rules

Overview

When alerts are received by ServiceNow they can be raised as a variety of different tasks (typically Incidents). Creation Rules set out the process for what gets raised as a task and the properties any raised tasks should have (the 'Assignment Group' for example). There are two types of rule that govern how incoming SCOM alerts are handled:

Creation Rules

These are the most common type of rule. They contain one or more filters that an incoming SCOM alert must match for the defined task to be raised. The raised task is then created using the settings defined in the rule and linked back to the matching alert record ensuring a clear record of events. They each have a defined processing order ensuring that they are prioritized against each other in a logical manner.

Wait Rules

Wait Rules allow an incoming SCOM alert to be held for a specified period of time before being evaluated against creation rules. They are useful for cases where a SCOM alert might open and close itself in quick succession (A.K.A - Flip flopping). If for example, this were something like a CPU monitor, you wouldn’t want a task or incident raised for a monitor that could have resolved itself before someone could take action. A Wait Rule could hold the alert for long enough to no longer meet the criteria for being raised formally.

Wait Rules are an in depth topic of their own and are covered in further detail here.

Anatomy of Creation Rules

Simple properties

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. The following screenshot shows what these will look like.

  • 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 in.

    • 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 say 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 in order 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.

Alert Conditions

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 there are no Creation Rules 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.

There is a detailed list of operators with further examples available under AlertSync Filter Operators.

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:

    • Incident (Default)

    • Problem

    • Change Request

    • Change Task

    • Service Task

    • Catalog Task

    • Task

  • 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 available here

  • Configuration Item/Fallback Configuration Item - A statically defined configuration item

    • When Automatically Map CI not enabled this will apply to every record created by this rule

    • When Automatically Map CI 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 - Added in 2.1 - The company that this record will be assigned to

    • If using Domain separation this is an easy way of tagging the required domain

Creating Your First Creation Rule

  1. Log in to ServiceNow, search for “Cookdown“ and select 'Creation Rules'

  2. Select 'New'

  3. Set a Name

    1. This should be concise but descriptive

  4. Tick the 'Active' checkbox

  5. Set a Processing Order

    1. For example 50

  6. Set an Alert Condition

    1. 'Alert Id is not empty' is a great way of selecting all alerts

    2. 'Resolution State is not Closed' is a great way of testing filtering

  7. Under ‘Incident / Task Creation’ set the Record Type to 'Incident'

  8. Set an Assignment Group and/or Assigned To value

    1. For testing purposes we recommend assigning to yourself to minimize impact

Your resulting Creation Rule should look something like the following:

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 are 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 are a distinct team within IT and need to handle all SQL related Incidents. They also want created Incidents raised against an SQL Configuration Item. All other Incidents are to be routed to a first-line Infrastructure team who try 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:

  1. Name - SQL Alerts

  2. Active - True

  3. Processing Order - 10

  4. Alert Condition - [Monitoring Object Display Name] [contains] [SQL]

  5. Record Type - Incident

  6. Configuration Item - MSSQLSERVER

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

  1. Name - Generic Infrastructure

  2. Active - True

  3. Processing Order - 50

  4. Alert Condition - [Alert Id] [Is not empty]

  5. Record Type - Incident

  6. Configuration Item - Infrastructure Services

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

Advanced Topics

Whilst this article should cover what you need to get going with Creation Rules, this is not all that they are capable of. Once you are more comfortable with or would like to override the default behavior of Creation Rules we would recommend visiting these advanced topics:

Search