Incident Custom Rules

The Incident Custom Rules page allows administrators to configure compliance checks that govern how incidents are processed, resolved, and closed. By defining these rules, organizations can ensure that technicians follow consistent processes, provide adequate documentation, and complete all dependent activities before an incident reaches its final state.

These rules act as safeguards to maintain data integrity, enforce communication standards, and align incident handling with organizational policies and ITSM best practices.

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

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

Resolved Rules

This tab allows administrators to define validation checks that must be met before an incident can be transitioned into the Resolved state. These rules ensure that technicians provide necessary information, maintain requester communication, and complete dependent activities prior to resolution. By configuring these rules, administrators can enforce organizational standards for resolution quality and accountability.

1. User Interaction

Defines communication requirements with the requester before resolving an incident.

• Request must have at least one communication with Requester: Ensures direct interaction with the end-user before marking the incident resolved.
• Request must have at least one note: Enforces that technicians add internal documentation or updates before resolution.

2. Mandatory Field

Specifies fields that must be completed before the incident can be resolved.

• Solution: Requires documenting the applied solution.
• Approval: Ensures necessary approvals are recorded.
• Diagnosis: Captures the root cause or analysis for transparency.
• Assignee: Ensures that a responsible technician is assigned to the incident.
• Technician Group: Requires assigning the incident to a valid group.
• Category: Ensures correct categorization of the incident.

3. Require State

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

• All Tasks must be closed: Prevents resolution if linked tasks are still pending.
• Request must have at least one worklog: Requires technicians to log work performed.
• All Changes must be closed: Linked changes must be completed before resolving the incident.
• All Secondary Requests must be closed: Associated or dependent requests must be resolved.
• All approvals must be Ignored/Rejected/Approved/Referred back: Ensures no pending approvals are left open.
• All Problems must be closed: Any linked problem records must be resolved.
• All Releases must be closed: Linked releases must be completed.

When Rules Are Enforced

Resolved Rules are checked whenever a technician attempts to move an incident into the Resolved state. If any required condition is unmet, the system prevents the transition until compliance is achieved.

Closed Rules

The Closed Rules section allows administrators to define specific compliance checks that must be satisfied before an incident can be closed. These rules ensure that all mandatory fields are updated, dependent requests and tasks are completed, and essential interactions with the requester are recorded. By enforcing these checks, you can maintain data quality and adherence to organizational processes.

The page is divided into three main sections:

1. User Interaction

Defines minimum communication requirements with the requester before closure.

• Request must have at least one communication with Requester: Ensures the technician has interacted with the end-user.
• Request must have at least one note: Ensures internal documentation is added before closure.

2. Mandatory Field

Specifies fields that must be filled out before the incident can be closed.

• Solution: A solution must be documented.
• Approval: Closure requires approval information if applicable.
• Diagnosis: The root cause or diagnosis must be recorded.
• Assignee: A technician must be assigned.
• Technician Group: The request must belong to a valid group.
• Category: The incident must be categorized properly.

3. Require State

Defines dependencies on related records and workflow states before the incident can be closed.

• All Tasks must be closed: Prevents closure if linked tasks remain open.
• All approvals must be Ignored/Rejected/Approved/Referred back: All approval items must be resolved.
• All Problems must be closed: Linked problem records must be completed.
• All Releases must be closed: Linked releases must be completed.
• Do not skip Resolved Status: Forces incidents to pass through the Resolved state before closure.
• Request must have at least one worklog: Ensures worklog entries are recorded.
• All Changes must be closed: Linked changes must be closed.
• All Secondary Requests must be closed: Associated requests must be completed.

When Rules Are Enforced

Closed Rules are evaluated when a technician attempts to close an incident. The system verifies:

• Mandatory fields are filled in.
• Communication and notes exist.
• All dependent items (tasks, approvals, changes, problems, releases) are resolved.
• At least one worklog entry is present.

If any required condition is not met, the incident cannot be closed until compliance is ensured.

Required Note Rules

The Required Note Rules section under Incident Custom Rules allows administrators to enforce that technicians add mandatory notes whenever specific actions are taken on an incident. This ensures proper documentation of decisions, updates, or state changes, which improves transparency, accountability, and audit readiness.

By configuring these rules, you can guarantee that important updates—such as changes in priority, assignment, or status—are always accompanied by explanatory notes.

The page contains the following categories of rules:

1. User Interaction

• Reopen: Enforces that a note must be added whenever an incident is reopened. This ensures technicians document the reason or context for reopening the incident.

2. Request Updated

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

• Assignee: A note must be added when changing the assigned technician.
• Technician Group: Requires a note when the request is moved to a different group.
• Urgency: Ensures justification when urgency is updated.
• Category: Captures reasoning when the incident is re-categorized.
• Support Level: Requires notes for changes in escalation/support tier.
• Due By: Enforces notes when SLA due dates are modified.
• Location: Requires a note when the incident’s location is updated.
• Priority: Captures justification when the request priority changes.
• Impact: Enforces documentation when impact values are updated.
• Source: Requires a note if the source of the request is changed.
• Department: Enforces notes when reassigning to another department.
• Status: Requires a note whenever the incident status is updated.

When Rules Are Enforced

Required Note Rules are triggered whenever a technician:

• Reopens an incident
• Updates any of the selected fields (e.g., Priority, Category, Status)

The system will prompt the technician to enter a note, and the action cannot be completed without one.

Show Dialog Rules

The Show Dialog Rules section allows administrators to configure confirmation prompts (dialogs) that appear when certain key fields of an incident are updated. These dialogs act as checkpoints to remind technicians of the importance of their changes, ensuring awareness, accuracy, and accountability.

This feature is particularly useful for sensitive fields such as Priority, Status, or Assignee, where updates may directly affect SLAs, escalations, or ownership.

The Show Dialog Rules page consists of a list of incident fields. When any of these fields are updated by a technician, a confirmation dialog is displayed before the update is applied.

Available Fields

• Assignee: Show a dialog when the incident is reassigned to another technician.
• Technician Group: Display confirmation when transferring incidents across groups.
• Urgency: Show a dialog when urgency level is updated.
• Category: Confirm changes to incident categorization.
• Support Level: Display a reminder when changing escalation or support tiers.
• Due By: Confirm changes to SLA due date.
• Location: Show a dialog when location details are updated.
• Priority: Confirm priority updates, since this affects SLAs and escalations.
• Impact: Show confirmation when changing impact assessment.
• Source: Display a dialog when altering the request’s source (e.g., email, portal).
• Department: Confirm when incidents are reassigned to a different department.
• Status: Show a dialog when the incident status is updated.

When Rules Are Enforced

Show Dialog Rules are triggered whenever a technician attempts to update one of the selected fields. Before the update is finalized, the system will display a confirmation dialog to ensure the technician validates the change.

Add Worklog Rules

The Add Worklog Rules section allows administrators to control which technicians are permitted to add worklog entries to an incident. Worklogs capture the time spent, activities performed, and updates made during incident handling. By restricting who can add worklogs, organizations can ensure accuracy, accountability, and cleaner audit trails.

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.

The Worklog Addition Access section provides four options for defining who can add worklogs:

• Only Assignee Only the technician assigned to the incident is allowed to add worklog entries. Use Case: When accountability is strictly tied to a single technician.

• Only Technician Group Any technician within the assigned group can add worklogs. Use Case: For group-based ownership where multiple team members may contribute.

• All Technicians Any technician in the system can add worklogs to the incident. Use Case: For collaborative environments where multiple teams may provide updates.

• Only Assignee or Technician Group Both the assigned technician and members of the assigned group can add worklogs. Use Case: When the primary assignee owns the ticket but team members may also contribute updates.

note

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

Example Scenario: When there is no technician assigned and someone tries to close the request, the system gives a validation message, and does not allow to close it.