Closure Rules Use Cases

Closure Rules Use Cases

Closure Rules 

Pointers 

  1. Closure rules automate the collection of vital details and execute relevant actions before a record can be closed in the service desk.
  2. Closure rules are not customer-specific.  
  3. Supported Modules: Requests, Problems, Changes, Releases, Purchase Orders, Tasks

Benefits

  1. Proper documentation of all essential details in each record before it is closed.
  2. Collect acknowledgement from users for the provided resolutions/services.
  3. Avoid violating SLAs by auto-closing resolved requests.
  4. Auto-close requests once the work divided into tasks/checklists is completed.  
 

Request Closure Rules  

Use case: Close requests only upon task completion 

Scenario:
When a new employee joins a company, the hiring manager raises an Employee Onboarding request through the help desk.
Before this request can be marked as Resolved, multiple departments such as IT, HR, and Facilities must complete their specific tasks.

For example,
IT Department:
  1. Create a user account in Active Directory
  2. Set up email and communication tools (e.g., Outlook, Teams)
  3. Assign laptop and accessories
Facilities Team:
  1. Prepare desk or office space
  2. Issue access badge
HR Team:
  1. Schedule orientation
  2. Verify documentation
Even if one team finishes its tasks, the overall request cannot be considered Resolved until all tasks and checklist items are completed, ensuring a smooth onboarding experience for the new hire.
Learn how to add tasks and checklists to requests.

Action:
To address this scenario, you can define a request closure rule stating that requests can be moved to Resolved only after completing all associated tasks and checklists.

Configuration:
 

Change Closure Rules 

Use case: Manage stage-wise closure

Scenario:
Zylker plans a network infrastructure upgrade in the data center. This could be a complex change request involving multiple systems, teams, and risk factors.

For example,
Phase
Key Activities
Closure Rule
Planning
Impact analysis, risk assessment, change schedule approval
Must be approved by Change Advisory Board (CAB) before proceeding
Implementation
Network equipment upgraded during a scheduled maintenance window
All implementation tasks and status must be marked as Completed.
Testing
Post-implementation testing, performance verification, rollback readiness check
Testing checklist must be marked as Passed by testing team
Review
Final review meeting with stakeholders, user confirmation, documentation updates
Change Manager must review and mark the CR as Ready for Closure
Closure
Official closure of the change record in the ITSM system
Auto-close after 5 days if no incidents or rollbacks are reported
 
Such high-risk or multi-phase change requests must not be subjected to premature closure.

Action:
  1. To avoid premature closure, you can enforce mandatory fields and require the completion of specific tasks or checklists in each phase before allowing progression to the next stage. 
  2. To auto-close if no incidents are reported, you can configure a Timer with a 5 days wait duration.
Sample Configuration:

    • Related Articles

    • Notification Rules Use Cases

      Notification Rules Pointers Supported Modules: Requests, Problems, Changes, Projects, Release, Solutions, Assets, Purchase, Contracts, Tasks, and other general events. Supported Notifications: Email, SMS, and Push. Actionable Messages can be enabled ...

    • Business Rules Use Cases

      Business Rules Pointers Incident and Service Request business rules are customer-specific and site-specific. Change business rules are neither customer-specific nor site-specific. However, you can apply change business rules for specific customers ...

    • Closure Rules

      Closure rules automate the collection of vital details and execute relevant actions before a record can be closed in the service desk. Supported Modules: Requests, Problems, Changes, Releases, Purchase Orders, Tasks Role Required: SDAdmin Benefits: ...

    • Workflows Use Cases

      Workflows Pointers Workflows can be configured for All Customers as well as for a specific customer, but not site-specific. This setting is module-specific. Separate workflows for incident requests and service requests can be configured. If an asset ...

    • Life Cycles Use Cases

      Life Cycles Pointers Life Cycles can be applied to All Customers or a specific customer. Life Cycles are not site-specific. However, you can apply life cycles for specific sites under Conditions. If a template is associated with a life cycle, the ...