Skip to content

Commit 5aa4aa8

Browse files
authored
Add README for enforcing CI maintenance window rules
This README provides details on enforcing CI maintenance windows for change requests, including configuration options and references to relevant APIs.
1 parent 6217e55 commit 5aa4aa8

File tree

1 file changed

+36
-0
lines changed
  • Server-Side Components/Business Rules/Enforce CI maintenance window on Change schedule

1 file changed

+36
-0
lines changed
Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
# Enforce CI maintenance window on Change schedule
2+
3+
## What this solves
4+
Change requests are sometimes scheduled outside the maintenance windows of the affected CIs, causing risky or blocked implementations. This rule validates the planned start and end times of a Change against the maintenance schedules of its related CIs and blocks the update if none of the CIs allow that window.
5+
6+
## Where to use
7+
- Table: `change_request`
8+
- When: before insert and before update
9+
- Order: early (for example 50)
10+
11+
## How it works
12+
- Looks up CIs related to the Change via `task_ci`
13+
- For each CI with a defined `maintenance_schedule` (reference to `cmn_schedule`), uses `GlideSchedule.isInSchedule` to verify the planned start and end are inside the window
14+
- If at least one CI’s maintenance schedule permits the window, the Change is allowed
15+
- If no related CI permits the window, the rule aborts the action with a clear message
16+
- Behaviour for CIs without a defined maintenance schedule is configurable
17+
18+
## Configure
19+
At the top of the script:
20+
- `BLOCK_WHEN_NO_SCHEDULE`: if true, treat CIs without a maintenance schedule as non-compliant
21+
- `REQUIRE_BOTH_BOUNDARIES`: if true, both planned start and planned end must be inside a permitted window
22+
- `TIMEZONE`: optional IANA time zone string (for example `Europe/London`); leave blank to use the schedule or instance default
23+
24+
## Notes
25+
- If your process requires all CIs to permit the window, change `anyPass` logic to `allPass`
26+
- This rule checks only maintenance windows defined on the CI record. If you store schedules at the Business Service level, adapt the CI lookup accordingly
27+
28+
## References
29+
- GlideSchedule API
30+
https://www.servicenow.com/docs/bundle/zurich-api-reference/page/app-store/dev_portal/API_reference/GlideSchedule/concept/c_GlideScheduleAPI.html
31+
- GlideDateTime API
32+
https://www.servicenow.com/docs/bundle/zurich-api-reference/page/app-store/dev_portal/API_reference/GlideDateTime/concept/c_GlideDateTimeAPI.html
33+
- Change Management fields
34+
https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/change-management/concept/change-management-overview.html
35+
- Task CI relationship (`task_ci`)
36+
https://www.servicenow.com/docs/bundle/zurich-servicenow-platform/page/product/configuration-management/reference/task-ci.html

0 commit comments

Comments
 (0)