Business Rules & Data Quality Pack

sn-control-001

Enforce Mandatory Closure Information

Business Rule Priority: Critical Effort: Low

To ensure that any bug closed from an early lifecycle state has proper justification, reducing ambiguity and providing data to analyze why tasks are closed without being worked.

Why this pack: This is a server-side data validation rule that enforces process discipline at a key lifecycle gate, which is the core function of a Business Rule.

Trigger

Task state changes to 'Closed'.

Conditions

·The previous state was 'New', 'Open', or 'Triage'.

·Closure code is empty OR Closure notes are empty.

Actions

·Abort the database transaction.

·Display an error message to the user: 'Closure Code and Closure Notes are mandatory when closing a bug from an early state.'

Evidence used

·Transition: Triage - Closed (122 tasks)

·Transition: New - Closed (96 tasks)

·Transition: Open - Closed (186 tasks)

·Variant: Open -> Closed is the most frequent variant (108 tasks)

ServiceNow implementation

Target table

·task

Configuration area

·Business Rule

Configuration trigger

·Before Insert/Update

Configuration conditions

·State | changes to | Closed

·AND Previous State | is one of | New, Open, Triage

·AND Closure Code | is empty

·OR Closure Notes | is empty

Implementation steps

·Create a new Business Rule on the target table for bugs.

·Set 'When to run' to 'Before' on 'Update'.

·In the 'Filter Conditions', specify 'State changes to Closed' and 'Previous state is one of New, Open, Triage'.

·In the 'Actions' tab, check 'Abort action'.

·Add a message: 'Closure Code and Closure Notes are mandatory when closing a bug from an early state.'

·Alternatively, use an Advanced script to check if close_code or close_notes are empty and use current.setAbortAction() and gs.addErrorMessage().

Fields used

·state

·close_code

·close_notes

Test cases

·Attempt to close a task from state 'Open' without filling in 'Closure Code'. The save should be aborted and an error message should appear.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·The target table must have 'Closure Code' and 'Closure Notes' fields.

sn-control-002

Standardize Priority Field Values

Dictionary Configuration Priority: High Effort: Low

To eliminate data inconsistency in the 'Priority' field by enforcing a single, standardized list of choices. This improves reporting accuracy, SLA calculation, and work prioritization.

Why this pack: This rule directly addresses data quality at the source by configuring the data dictionary, which is a fundamental data governance control.

Trigger

User opens a form containing the 'Priority' field.

Conditions

·The 'Priority' field is displayed on the form.

Actions

·Modify the dictionary entry for the 'Priority' field.

·Define a standard choice list (e.g., 1-Critical, 2-High, 3-Medium, 4-Low).

·Set a default value and make the field mandatory to prevent NULL entries.

Evidence used

·Field usage for 'Priority' shows mixed value sets: ('Major', 'Minor', 'Critical', 'Blocker') and ('High', 'Medium', 'Trivial', 'Urgent').

·3 tasks have a NULL value for Priority, indicating it is not always mandatory.

ServiceNow implementation

Target table

·task

Configuration area

·Dictionary

Configuration trigger

·Form Load

Configuration conditions

·N/A - Dictionary entry applies globally.

Implementation steps

·Navigate to System Definition > Dictionary and find the entry for the 'Priority' field on the target table.

·In the 'Choices' related list, deactivate or delete non-standard choices like 'Major', 'Minor', 'Blocker', 'Optional', 'Trivial', 'Urgent'.

·Add or confirm a standard set of choices (e.g., Critical, High, Medium, Low) with appropriate sequence numbers.

·In the 'Dictionary Entry' form, set a 'Default value' and check the 'Mandatory' box.

·A one-time data cleanup script should be run to migrate old values to the new standard.

Fields used

·priority

Test cases

·Open a new task form. The 'Priority' field should be mandatory, have a default value, and only show the standardized choices.

Rollback notes

·Re-activate the previous choice list values in the dictionary. Uncheck 'Mandatory' and remove the default value.

Requirements / prerequisites

·Administrative access to modify dictionary entries.

·Agreement on a standardized list of priority values.

sn-control-003

Require Justification for Reopening Closed Tasks

Business Rule Priority: High Effort: Low

To control the 'Closed -> Reopened' rework loop by forcing the user to provide a reason in the work notes, improving auditability and understanding of why resolutions fail.

Why this pack: This is a server-side business rule that enforces a data quality and audit requirement (adding a work note) during a specific state transition, preventing silent rework.

Trigger

Task state changes from 'Closed'.

Conditions

·The new state is 'Reopened' (or another active state like 'Open' or 'In Progress').

·Work notes have not been updated during the transaction.

Actions

·Abort the database transaction.

·Display an error message to the user: 'Please add a Work Note explaining why this task is being reopened.'

Evidence used

·Transition: Closed - Reopened (65 tasks, 3.07%) represents a significant rework loop.

ServiceNow implementation

Target table

·task

Configuration area

·Business Rule

Configuration trigger

·Before Update

Configuration conditions

·State | changes from | Closed

Implementation steps

·Create a new Business Rule on the target table for bugs.

·Set 'When to run' to 'Before' on 'Update'.

·In the 'Filter Conditions', specify 'State changes from Closed'.

·In the 'Advanced' tab, add a script: if (current.work_notes.getJournalEntry(1) == '') { gs.addErrorMessage('A work note is required to reopen a task.'); current.setAbortAction(true); }

·Ensure the condition also checks that the new state is an active one, not another terminal state.

Fields used

·state

·work_notes

Test cases

·Open a 'Closed' task. Change the state to 'Reopened' and try to save without adding a work note. The save should fail with an error message.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·A 'Reopened' state or similar active state must exist in the state model.

sn-control-004

Gate 'New' State Exit on Required Data

Data Policy Priority: Medium Effort: Low

To prevent tasks from leaving the 'New' state without essential triage information, such as an assigned team. This addresses the 'New -> New' self-loop, which indicates tasks are stalling at intake.

Why this pack: A Data Policy is a server-side control that enforces data consistency and completeness regardless of the source (UI, integration), making it a robust data quality tool.

Trigger

A task record is updated where the state is not 'New'.

Conditions

·State is not 'New'.

Actions

·Make the 'Assignment Group' and 'Project' fields mandatory.

Evidence used

·Transition: New - New (131 tasks, 6.19%) is a high-volume self-loop, suggesting updates are made without progressing the task.

·Variant: 'New -> New -> Open...' exists, confirming this is a rework pattern.

ServiceNow implementation

Target table

·task

Configuration area

·Data Policy

Configuration trigger

·On Insert/Update

Configuration conditions

·State | is not | New

Implementation steps

·Navigate to System Policy > Data Policies and create a new one.

·Set the 'Table' to the target table for bugs.

·In the 'Conditions' builder, set 'State is not New'.

·In the 'Data Policy Rules' related list, create a new rule for the 'Assignment Group' field and check 'Mandatory'.

·Create another rule for the 'Project' field and check 'Mandatory'.

Fields used

·state

·assignment_group

·project

Test cases

·Create a new task (in 'New' state) without an Assignment Group. Save it. Now, change the state to 'Open' and try to save. The save should be blocked until an Assignment Group is provided.

Rollback notes

·Deactivate the Data Policy.

Requirements / prerequisites

·The 'Project' field must exist on the target table.

sn-control-005

Prevent Direct 'Open' to 'Closed' State Transition

Business Rule Priority: Medium Effort: Medium

To enforce the standard process flow and prevent teams from skipping the 'Resolved' or 'Verified' steps. This ensures resolution details are captured and that a formal resolution/verification has occurred.

Why this pack: This Business Rule enforces a specific process sequence, a key governance control to reduce process variation and improve data quality for cycle time analysis.

Trigger

Task state changes to 'Closed'.

Conditions

·The previous state was 'Open' or any other early-stage active state (e.g., 'Coding In Progress').

Actions

·Abort the database transaction.

·Display an error message: 'Tasks must be moved to a Resolved state before they can be Closed.'

Evidence used

·Variant 'Open -> Closed' is the most frequent path with 108 tasks (5.10%).

·The process has distinct 'Resolved', 'Ready for QA', and 'Verified' states that are being bypassed by this variant.

ServiceNow implementation

Target table

·task

Configuration area

·Business Rule

Configuration trigger

·Before Update

Configuration conditions

·State | changes to | Closed

·AND Previous State | is | Open

Implementation steps

·Create a new Business Rule on the target table for bugs.

·Set 'When to run' to 'Before' on 'Update'.

·In the 'Filter Conditions', specify 'State changes to Closed' AND 'Previous State is Open'.

·In the 'Actions' tab, check 'Abort action' and add a message: 'Tasks must be moved to a Resolved state before being Closed. Please resolve the task first.'

·This rule can be expanded to include other invalid from/to transitions based on the defined state model.

Fields used

·state

Test cases

·Open a task in the 'Open' state. Attempt to change its state directly to 'Closed'. The save should be aborted with an error message.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·A clearly defined state model that outlines valid transitions.