Change Custom Rules

The Change Custom Rules page allows administrators to configure compliance checks that govern how changes are processed through their lifecycle. By defining these rules, organizations can ensure that change records are complete, all prerequisites are met at each stage, and proper documentation is maintained.

These rules act as safeguards to enforce change management policies, maintain data integrity, and align change execution with ITSM best practices.

To view the Change Custom Rules page, navigate to Admin > Change Management > Change Custom Rules.

The page is organized into multiple rule categories, each accessible from the left-hand panel:

Submitted Rules

This tab allows administrators to define validation checks that must be met before a change can be moved into the Submitted state. These rules ensure that essential information is captured at the time of submission.

1. Mandatory Field

Specifies fields that must be completed before the change can be submitted.

• Assignee: Ensures a responsible technician is assigned to the change.
• Technician Group: Requires assigning the change to a valid group.
• Change Manager: A Change Manager must be assigned to oversee the change.
• Location: Requires specifying the location affected by the change.
• Category: Ensures correct categorization of the change.

Planning Rules

This tab allows administrators to define validation checks that must be met before a change can enter the Planning stage. These rules ensure that all necessary plans and impact assessments are documented.

1. Mandatory Field

Specifies fields that must be completed before the change moves to planning.

• Assignee: Ensures a responsible technician is assigned.
• Technician Group: Requires assigning the change to a valid group.
• Rollout Plan: A detailed rollout plan must be documented.
• Change Schedule Plan: The schedule for the change must be planned and recorded.
• Location: Requires specifying the location.
• Category: Ensures correct categorization.
• Planning-Impact: The potential impact of the change must be assessed and documented.
• Backout Plan: A plan for reverting the change if it fails must be documented.

Implementation Rules

This tab allows administrators to define validation checks that must be met before a change can be moved to the Implementation stage. These rules ensure that the change is ready for execution and all dependencies are resolved.

1. Mandatory Field

Specifies fields that must be completed before the change can be implemented.

• Assignee: Ensures a responsible technician is assigned.
• Technician Group: Requires assigning the change to a valid group.
• Change Implementor: The technician responsible for implementation must be assigned.
• Location: Requires specifying the location.
• Category: Ensures correct categorization.

2. Require State

Defines related items or dependencies that must be completed prior to implementation.

• All Tasks must be closed: Prevents implementation if any linked tasks are still pending.

Review Rules

This tab allows administrators to define validation checks that must be met before a change can be moved into the Review stage. These rules ensure that implementation details are documented and the change is ready for post-implementation analysis.

1. Mandatory Field

Specifies fields that must be completed before the change can be reviewed.

• Assignee: Ensures a responsible technician is assigned.
• Change Reviewer: The person responsible for reviewing the change must be assigned.
• Technician Group: Requires assigning the change to a valid group.

2. Require State

• Change must have at least one worklog: Ensures that work has been logged against the change before it is reviewed.

Required Note Rules

The Required Note Rules section allows administrators to enforce that technicians add mandatory notes whenever specific actions or field changes occur on a change request. This improves transparency and accountability throughout the change lifecycle.

1. User Interaction

• Reopen: Enforces that a note must be added whenever a change is reopened.
• Planning: Cancelled: Requires a note when a change is cancelled during the planning phase.
• Review: Failed: Requires a note when a change fails its review.
• Submitted: Rejected: Requires a note when a submitted change is rejected.
• Implementation: Rejected: Requires a note when an implementation is rejected.
• Review: Completed: Requires a note when the review is completed.

2. Change Updated

Specifies which field changes require the technician to provide a note.

• Assignee: A note must be added when changing the assigned technician.
• Technician Group: Requires a note when the change is moved to a different group.
• Urgency: Ensures justification when urgency is updated.
• Department: Enforces notes when reassigning to another department.
• Location: Requires a note when the change’s location is updated.
• Priority: Captures justification when the change priority is updated.
• Category: Captures reasoning when the change is re-categorized.
• Status: Requires a note whenever the change status is updated.

Show Dialog Rules

The Show Dialog Rules section allows administrators to configure confirmation prompts that appear when certain key fields of a change are updated. These dialogs act as checkpoints to ensure awareness and prevent accidental changes.

Change Updated

• Assignee: Show a dialog when the change is reassigned to another technician.
• Technician Group: Display confirmation when transferring changes across groups.
• Urgency: Show a dialog when urgency level is updated.
• Department: Confirm when changes are reassigned to a different department.
• Location: Show a dialog when location details are updated.
• Priority: Confirm priority updates.
• Category: Confirm changes to change categorization.
• Status: Show a dialog when the change status is updated.

Add Worklog Rules

The Add Worklog Rules section allows administrators to control which technicians are permitted to add worklog entries to a change.

Check whether the user has permission to add work log. The "Add Worklog" button appearing in the Worklog tab of the respective ticket's details page will be unavailable if the user is not given access.

Worklog Addition Access

• Only Assignee: Only the technician assigned to the change is allowed to add worklog entries.
• Only Technician Group: Any technician within the assigned group can add worklogs.
• All Technicians: Any technician in the system can add worklogs to the change.
• Only Assignee or Technician Group: Both the assigned technician and members of the assigned group can add worklogs.

note

Tasks created without any reference module will not have any configuration; hence, all technicians can add a worklog.

Example Scenario: You cannot create a task when the change is on Approval stage.