CI Maintenance During Outage

[SumantK]

Hi All, 

We have a requirement such that all affected CIs in a change record should have outage records for all the affected CIs that get added in the change record and outage window should be adjustable until change implementation time is completed.

Now all the CIs should go into maintenance (em_impact_maint_ci) table during during outage window specified as per the specific CI, as actual outage can vary for each CI as per the actual activity time, which can be adjusted during actual change implementation time. 

Is there any possibility to achieve this customization ?

Regards,

Sumant

[Bhuvan]

@SumantK 

Yes, it is feasible. Follow below article for more details

https://www.servicenow.com/community/developer-forum/copy-change-affected-cis-to-outage-record/m-p/2...

If this helped to answer your query, please mark it helpful & accept the solution. 

Thanks,

Bhuvan

[MackI]

hi @SumantK 

Based on the provided sources, it's possible to achieve your customisation requirements within ServiceNow, though it would involve leveraging existing functionalities alongside custom development.
Here's a breakdown of how your requirements can be met:
1. All affected CIs in a change record should have outage records for all the affected CIs that get added in the change record:
• Affected CIs on a Change Record: ServiceNow's Change Management allows you to associate multiple Configuration Items (CIs) with a single change request using the "Affected CIs" related list (task_ci table). This list can be populated manually or dynamically.
• Creating Outage Records: The "Create Outage" UI action is available on the Change Request form for new instances from Jakarta onwards. This action typically creates a single outage record.
• Associating CIs with Outages: Outage records can be associated with multiple CIs using the "Affected CIs" related list on the outage form. When an outage is opened against a business or technical service, all child offerings are added to the Affected CIs related list on the outage form.
• Customisation for Multiple Outages: To automatically create individual outage records for each affected CI or to automatically associate all affected CIs to a single new outage record when they are added to the change record, you would need to implement custom business rules or workflows. This customisation would trigger when CIs are added to the "Affected CIs" list of the change request or when the change record reaches a specific state (e.g., 'Scheduled' or 'Implement'). The script would then iterate through the affected CIs and create or link the necessary outage records.
2. Outage window should be adjustable until change implementation time is completed:
• Change Request Dates: Change requests have fields for "Planned start date," "Planned end date," "Actual start date," and "Actual end date". The "Actual start date" and "Actual end date" are typically populated manually during the 'Implement' state as the work begins and completes.
• Outage Record Dates: Outage records also have "Begin" and "End" date/time fields. The "End" date can be manually entered or set with an "End Outage Now" related link when the outage concludes.
• Adjustability: This aligns directly with your requirement. You can manually adjust the "Begin" and "End" times of the associated outage records. Furthermore, the "Planned start date" and "Planned end date" on the change request itself are modifiable, especially to resolve detected conflicts.
• Scheduling Tools: The Change Schedule provides a timeline view of changes, including their timing, duration, blackout periods, and maintenance windows. The Service Operations Workspace (SOW) also offers a "Schedule" tab on the change request form, which displays maintenance windows and allows rescheduling to find "Next conflict-free" times if conflicts arise.
• Custom Automation for Real-time Updates: You could implement a custom business rule or workflow to automatically update the "Begin" and "End" fields of the associated outage records when the "Actual start date" and "Actual end date" fields on the parent change request or its related tasks are updated during the 'Implement' state. This would ensure the outage windows are dynamically adjusted based on the actual activity time for each CI.
3. All CIs should go into maintenance (em_impact_maint_ci) table during the outage window specified as per the specific CI, as actual outage can vary for each CI as per the actual activity time, which can be adjusted during actual change implementation time:
• Maintenance Schedules: ServiceNow natively supports Maintenance Schedules, which specify periods during which change requests should be scheduled. These schedules are crucial for conflict detection.
• Defining CI-Specific Maintenance Windows: There are two main ways to define maintenance schedules for conflict detection:
1. Configure maintenance schedule: This is enabled by the change.conflict.currentwindow system property. These schedules are processed based on conditions to determine their applicability to the change request or associated Affected CIs. This method is suited for generic schedules applying to many CIs.
2. Create maintenance schedule using Schedules table (cmn_schedule): This is enabled by the change.conflict.ci_maint_sched system property. This method is designed for individual CIs or small groups of CIs that need specific, tailored schedules. In this case, the Type field of the schedule record (in cmn_schedule) must be set to 'maintenance' and then referenced in the "Maintenance schedule" field directly on the CI record. This directly supports your requirement for varying actual outage times per CI.
• em_impact_maint_ci Table: While the ServiceNow sources/documentation  extensively discuss cmn_schedule_maintenance and cmn_schedule for defining maintenance windows, the table em_impact_maint_ci is not explicitly mentioned within the provided text as the primary table for defining these schedules. It is a common understanding (outside these sources, therefore, you may want to independently verify this information) that em_impact_maint_ci is typically used by Event Management (part of IT Operations Management) to track CIs that are currently in a maintenance window, often for the purpose of suppressing alerts during planned work. The existence and configuration of maintenance schedules in cmn_schedule or cmn_schedule_maintenance would feed into this functionality.
• Conflict Detection and Maintenance Windows: When a CI with an assigned maintenance schedule is used in a change request, conflict detection will automatically determine if the planned work falls outside the defined maintenance window and display a conflict error message. This ensures adherence to specified maintenance windows.
• Adjusting during Implementation: As discussed above, the ability to record "Actual start date" and "Actual end date" for changes and outages allows for dynamic adjustment. A custom business rule or workflow could be implemented to ensure that as these actual times are captured during implementation, the relevant maintenance schedules (or associated outage records that represent the maintenance period) are updated accordingly.

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌ OR  mark it  Helpful ‌⛑‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community