Business Rules & Data Quality Pack

Chaotic-1

⚙ Technical Requirements

ServiceNow scoped application / admin access

Relevant ServiceNow product/plugins for the selected pack capability

Validate in sub-production before promoting through update sets or application repository

Automation Readiness: High — The process mining data clearly identifies rework loops and data quality gaps that can be directly addressed with standard ServiceNow business rules and data policies.

Business Rules & Data Quality Pack — 4 rules

sn-control-001

Enforce Mandatory Close Code and Notes

Business Rule Priority: Critical Effort: Low

To ensure every resolved incident is properly categorized for reporting and analysis by making the close code and close notes mandatory before an incident can be set to Resolved or Closed. This addresses a significant data quality gap where 6.5% of incidents are closed with no close code.

Why this pack: This is a fundamental data quality control that uses a Business Rule to enforce process discipline at a key lifecycle gate (resolution), which is the core purpose of this pack.

Trigger

Incident state changes to 'Resolved' or 'Closed'

Conditions

·State changes to 'Resolved' OR State changes to 'Closed'

·Close code is empty OR Close notes is empty

Actions

·Prevent the state change

·Display an error message to the user: 'Close Code and Close Notes are mandatory to resolve or close an incident.'

Evidence used

·Field usage: 'close_code', 'values': [{'value':'None', 'tasks': 129, 'perc_total_tasks': 6.5}]

·Sample tasks INC0015155, INC0015214, and INC0015918 have a close_code of 'None'

ServiceNow implementation

Target table

·incident

Configuration area

·Business Rule

Configuration trigger

·Before Update

Configuration conditions

·current.state.changesTo(6) || current.state.changesTo(7)

·current.close_code.nil() || current.close_notes.nil()

Implementation steps

·Create a 'before' update Business Rule on the incident table.

·In the 'When to run' tab, set the filter conditions: 'State changes to Resolved' OR 'State changes to Closed'.

·In the 'Advanced' tab, add a script to check if close_code or close_notes are empty.

·If either field is empty, use 'gs.addErrorMessage()' to display a message and 'current.setAbortAction(true)' to stop the update.

Fields used

·state

·close_code

·close_notes

Test cases

·Attempt to change an incident state to 'Resolved' without filling in the 'Close code' and 'Close notes'. The action should be aborted and an error message shown.

·Attempt to change an incident state to 'Resolved' after filling in both 'Close code' and 'Close notes'. The action should succeed.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·Admin access to create Business Rules.

·Defined integer values for 'Resolved' (e.g., 6) and 'Closed' (e.g., 7) states.

sn-control-002

Require Work Note on Incident Re-open

Business Rule Priority: High Effort: Low

To capture the reason why a previously resolved incident is being re-opened. This addresses the 'Resolved -> Work in Progress' rework transition by forcing documentation, which is crucial for root cause analysis of resolution failures.

Why this pack: This rule uses a server-side Business Rule to enforce data entry (a work note) during an auditable process step (re-opening a task), directly improving data quality and process adherence.

Trigger

Incident state changes from 'Resolved' to an active state

Conditions

·State changes from 'Resolved' to any state that is not 'Closed'

·Work notes have not been updated in the current transaction

Actions

·Prevent the state change

·Display an error message: 'A work note is required to re-open a resolved incident.'

Evidence used

·Transition: 'Resolved - Work in Progress', 'From Activity':'Resolved','To Activity':'Work in Progress','Work items':27,'Is rework?':true

ServiceNow implementation

Target table

·incident

Configuration area

·Business Rule

Configuration trigger

·Before Update

Configuration conditions

·previous.state == 6 && current.state != 7

Implementation steps

·Create a 'before' update Business Rule on the incident table.

·In the 'When to run' tab, set the filter condition: 'State changes from Resolved'.

·In the 'Advanced' tab, add a script to check 'if (current.work_notes.getJournalEntry(1) == '')'.

·If there are no new work notes, use 'gs.addErrorMessage()' and 'current.setAbortAction(true)'.

Fields used

·state

·work_notes

Test cases

·Change an incident state from 'Resolved' to 'Work in Progress' without adding a work note. The update should fail.

·Add a work note and change the state from 'Resolved' to 'Work in Progress'. The update should succeed.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·Admin access to create Business Rules.

·Defined integer values for 'Resolved' (e.g., 6) and 'Closed' (e.g., 7) states.

sn-control-003

Require Work Note on 'In Progress' Reassignment

Business Rule Priority: High Effort: Low

To reduce ticket 'ping-pong' by requiring a clear justification when an incident is reassigned after work has already started. This addresses the 'Work in Progress -> Assigned' rework loop, providing data to improve initial triage and assignment accuracy.

Why this pack: This rule enforces the capture of critical context (the 'why' of a handoff) using a Business Rule, which is a core data quality and process governance control.

Trigger

Assignment group changes on an incident that is 'Work in Progress'

Conditions

·State is 'Work in Progress'

·Assignment group changes

·Work notes have not been updated in the current transaction

Actions

·Prevent the assignment change

·Display an error message: 'A work note is required to reassign an incident that is in progress.'

Evidence used

·Transition: 'Work in Progress - Assigned', 'From Activity':'Work in Progress','To Activity':'Assigned','Work items':139,'% total tasks':'6.95','Is rework?':true

ServiceNow implementation

Target table

·incident

Configuration area

·Business Rule

Configuration trigger

·Before Update

Configuration conditions

·current.state == <Work in Progress value>

·current.assignment_group.changes()

Implementation steps

·Create a 'before' update Business Rule on the incident table.

·In the 'When to run' tab, set filter conditions: 'State is Work in Progress' AND 'Assignment group changes'.

·In the 'Advanced' tab, add a script to check 'if (current.work_notes.getJournalEntry(1) == '')'.

·If no new work notes are present, use 'gs.addErrorMessage()' and 'current.setAbortAction(true)'.

Fields used

·state

·assignment_group

·work_notes

Test cases

·With an incident in 'Work in Progress' state, change the Assignment Group without adding a work note. The update should fail.

·With an incident in 'Work in Progress' state, add a work note and change the Assignment Group. The update should succeed.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·Admin access to create Business Rules.

·Defined integer value for 'Work in Progress' state.

sn-control-004

Require Work Note for 'Pending' States

Business Rule Priority: Medium Effort: Low

To improve clarity and communication by requiring agents to document why an incident is being placed in a pending or waiting state. This addresses the confusing and frequent rework transitions involving 'Pending User' and 'Awaiting User Info', ensuring there is a clear record of what is being waited on.

Why this pack: This data quality rule ensures that state changes to non-active states are accompanied by explanatory data, improving the audit trail and transparency. It's a classic process control implemented via a Business Rule.

Trigger

Incident state changes to 'Pending User' or 'Awaiting User Info'

Conditions

·State changes to 'Pending User' OR State changes to 'Awaiting User Info'

·Work notes have not been updated in the current transaction

Actions

·Prevent the state change

·Display an error message: 'Please add a work note explaining why this incident is being put on hold.'

Evidence used

·Transition: 'Work in Progress - Pending User', 'Work items': 860, '% total tasks': '43.00', 'Is rework?': true

·Transition: 'Pending User - Awaiting User Info', 'Work items': 422, '% total tasks': '21.10', 'Is rework?': true

ServiceNow implementation

Target table

·incident

Configuration area

·Business Rule

Configuration trigger

·Before Update

Configuration conditions

·current.state.changesTo(<Pending User value>) || current.state.changesTo(<Awaiting User Info value>)

Implementation steps

·Create a 'before' update Business Rule on the incident table.

·In the 'When to run' tab, set filter conditions: 'State changes to Pending User' OR 'State changes to Awaiting User Info'.

·In the 'Advanced' tab, add a script to check 'if (current.work_notes.getJournalEntry(1) == '')'.

·If no new work notes are present, use 'gs.addErrorMessage()' and 'current.setAbortAction(true)'.

Fields used

·state

·work_notes

Test cases

·Attempt to change the incident state to 'Awaiting User Info' without adding a work note. The update should be blocked.

·Add a work note explaining what information is needed from the user and then change the state to 'Awaiting User Info'. The update should succeed.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·Admin access to create Business Rules.

·Defined integer values for 'Pending User' and 'Awaiting User Info' states.