Service Request Custom Rules

The custom rules help you to enforce the organization’s compliance while processing a service request. Using these rules you can ensure that any change in the service request attributes is supported by proper comments or notes. For example, a serivce request should not move to the resolved state if there is no technician assigned to it. Similarly, you can use custom rules to enforce the approval workflows and closing tasks to close a request.

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

note

These rules are applicable to all the requests.

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

Resolved Rules

The Resolved Rules section allows administrators to configure mandatory validations that must be met before a service request can be transitioned into the Resolved state. These rules help ensure that service requests are properly documented, approvals are completed, and dependent tasks or records are closed before resolution.

The Resolved Rules page is divided into the following sections:

1. User Interaction

Defines communication requirements with the requester before a service request can be marked as resolved.

• Request must have at least one communication with Requester: Ensures direct communication with the end-user.
• Request must have at least one note: Enforces that internal notes or documentation are recorded.

2. Mandatory Field

Specifies fields that must be filled before resolving a service request.

• Solution: Requires documentation of the implemented solution or service delivered.
• Approval: Ensures approvals are logged before resolution.
• Diagnosis: Captures problem analysis or troubleshooting notes (if applicable).
• Assignee: Requires the request to be assigned to a technician.
• Technician Group: Ensures the request is mapped to a valid group.
• Category: Enforces proper categorization of the service request.

3. Require State

Defines related states and dependencies that must be satisfied before resolution.

• All Tasks must be closed: Ensures no open tasks remain.
• Request must have at least one worklog: Requires logging of technician activities.
• All Changes must be closed: Linked changes must be completed.
• All Secondary Requests must be closed: Associated service requests must be resolved.
• All approvals must be Ignored/Rejected/Approved/Referred back: No pending approvals should remain.
• All Problems must be closed: Ensures linked problem records are resolved.
• All Releases must be closed: Enforces closure of linked releases before request resolution.

When Rules Are Enforced

These rules are validated when a technician attempts to move a service request into the Resolved state. If any required condition is not met, the request cannot be resolved until compliance is ensured.

Closed Rules

The Closed Rules section allows administrators to define compliance checks that must be satisfied before a service request can be closed. These rules ensure that the request lifecycle is fully completed, with all approvals, tasks, and dependencies resolved, and with adequate documentation recorded.

By enforcing these rules, organizations can prevent premature closure of service requests and maintain consistency with service delivery standards.

The Closed Rules page is divided into three sections:

1. User Interaction

Ensures that technicians maintain minimum communication and documentation before closure.

• Request must have at least one communication with Requester: Validates that end-user engagement is recorded.
• Request must have at least one note: Enforces that internal notes are added for auditing.

2. Mandatory Field

Defines which fields must be updated before the request can be closed.

• Solution: Requires documentation of the delivered service.
• Approval: Ensures closure only after necessary approvals are captured.
• Diagnosis: Captures troubleshooting details (if applicable).
• Assignee: Enforces assignment to a technician before closure.
• Technician Group: Ensures the request is mapped to a support group.
• Category: Requires categorization for reporting and tracking.

3. Require State

Specifies dependencies that must be satisfied before closure.

• All Tasks must be closed: Prevents closure if related tasks are pending.
• All approvals must be Ignored/Rejected/Approved/Referred back: Ensures that no approvals remain open.
• All Problems must be closed: Any linked problems must be resolved.
• All Releases must be closed: Prevents closure if linked releases are pending.
• Do not skip Resolved Status: Ensures the request passes through Resolved before Closed.
• Request must have at least one worklog: Requires at least one technician worklog entry.
• All Changes must be closed: Any linked change requests must be resolved.
• All Secondary Requests must be closed: Prevents closure if associated service requests are still active.

When Rules Are Enforced

Closed Rules are validated when a technician attempts to close a service request. If any configured condition is not met, the request cannot be closed until compliance is ensured.

Required Note Rules

The Required Note Rules section allows administrators to enforce that technicians add mandatory notes whenever specific actions are performed on a service request. This ensures accountability and maintains proper documentation for auditing and service transparency.

For example, if a service request is reopened or if critical fields such as Priority or Assignee are updated, the technician will be required to provide a note explaining the reason for the action.

The Required Note Rules page includes two categories of rules:

1. User Interaction

• Reopen – Enforces that a note must be added whenever a service request is reopened.
  Purpose: Ensures the reason for reopening is documented for clarity and tracking.

2. Service Catalog Updated

Specifies field updates that require a note from the technician.

• Assignee – Require a note when the assigned technician is changed.
• Technician Group – Enforce notes when the request is reassigned to a different support group.
• Urgency – Capture justification when urgency is updated.
• Category – Require documentation when the request is re-categorized.
• Support Level – Enforce notes when the escalation/support level is changed.
• Due By – Require a note when the SLA due date is updated.
• Location – Enforce notes when the service location is changed.
• Priority – Require a note when the priority level is modified.
• Impact – Capture reasoning when the impact assessment is changed.
• Source – Require notes when the source of the request is updated (e.g., email, portal, phone).
• Department – Enforce notes when the request is reassigned to another department.
• Status – Require notes when the request status is updated.

When Rules Are Enforced

Required Note Rules are triggered whenever a technician:

• Reopens a service request
• Updates any of the selected fields (e.g., Priority, Category, Status, or Due By)

The system prompts the technician to enter a note, and the update cannot be completed without it.

Show Dialog Rules

The Show Dialog Rules section allows administrators to configure confirmation dialogs that appear whenever specific fields in a service request are updated. These dialogs serve as checkpoints, prompting technicians to confirm their changes before they are applied.

This helps prevent accidental updates to critical fields such as Priority, Status, or Assignee, thereby improving accuracy and accountability in service request management.

The Show Dialog Rules page lists key service request fields. When any of the selected fields are updated, the system displays a confirmation dialog before saving the changes.

Service Catalog Updated Fields

• Assignee – Show a dialog when the service request is reassigned to another technician.
• Technician Group – Display confirmation when transferring the request to a different support group.
• Urgency – Show a dialog when the urgency level is modified.
• Category – Display a confirmation when the service request category is updated.
• Support Level – Prompt confirmation when changing the escalation/support tier.
• Due By – Confirm when SLA due dates are updated.
• Location – Display a dialog when the location is changed.
• Priority – Confirm updates to request priority (important for SLA impact).
• Impact – Show a dialog when the request’s impact assessment is updated.
• Source – Display a confirmation when the request source is changed (e.g., portal, email, phone).
• Department – Prompt confirmation when the request is reassigned to another department.
• Status – Show a dialog when the request status is updated.

When Rules Are Enforced

Dialog rules are enforced whenever a technician attempts to update one of the selected fields. The system will display a confirmation message such as:

“You are about to change the Priority of this service request to High. Do you want to continue?”

The technician must confirm the action before the update is applied.

Add Worklog Rules

The Add Worklog Rules section allows administrators to define which technicians are permitted to add worklog entries to a service request. Worklogs record time spent, activities performed, and progress made during the lifecycle of a service request.

By restricting who can add worklogs, organizations can ensure accountability, improve audit readiness, and maintain accurate records of technician activities.

The Worklog Addition Access options define who is allowed to add worklog entries:

• Only Assignee
  Only the assigned technician can add worklog entries.
  Use Case: Enforces strict accountability by limiting worklog ownership to a single technician.

• Only Technician Group
  Any member of the assigned support group can add worklogs.
  Use Case: Useful in team-based assignments where multiple technicians may contribute.

• All Technicians
  Any technician in the system can add worklogs to the service request.
  Use Case: Suitable for collaborative environments where cross-team updates are common.

• Only Assignee or Technician Group
  Both the assigned technician and members of the assigned group can add worklogs.
  Use Case: Balances individual accountability with group collaboration.

When Rules Are Enforced

The configured worklog access rules are applied whenever a technician attempts to add a worklog entry. If the technician does not meet the access conditions, the system prevents them from adding the worklog.

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.