--- title: Create blackout and maintenance schedules in Change Management description: Use the Blackout and Maintenance windows to schedule a change. Blackout windows specify times during which normal change activity should not be scheduled. Maintenance windows specify times during which change requests should be scheduled. For example, create a blackout schedule for code freezes at the end of the year. locale: en-US canonical_url: https://www.servicenow.com/docs/r/it-service-management/change-management/t\_CreateBlkoutMaintSched.html release: brazil product: Change Management classification: change-management topic_type: task last_updated: "2026-09-10" reading_time_minutes: 8 breadcrumb: [Conflict detection, Configure, Change Management, IT Service Management] --- # Create blackout and maintenance schedules in Change Management Use the Blackout and Maintenance windows to schedule a change. Blackout windows specify times during which normal change activity should not be scheduled. Maintenance windows specify times during which change requests should be scheduled. For example, create a blackout schedule for code freezes at the end of the year. ## Before you begin Role required: itil\_admin or admin The [Change Management - Collision Detector](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/it-service-management/change-management/t_ActivateConflictDetection.md) plugin \(com.snc.change.collision\) must be active. ## About this task Conflict detection uses blackout and maintenance schedules to find potential scheduling conflicts for the configuration items \(CIs\) associated with a change request. When conflict detection runs, either automatically or by manual request, conflict detection determines if either type of defined schedule applies to the change request. If a potential conflict is identified, a warning message appears and conflicts are listed within the Conflict form section. View conflicts in the [Conflict calendar](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/it-service-management/change-management/change-conflict-calendar.md). **Note:** To use the business service as the source for a blackout or maintenance schedule, the business service must be converted to an application service. For instructions, see [Convert business services to application services](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/servicenow-platform/convert-bus-to-app-svc-intro.md). For information about application services, see [Application services](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/servicenow-platform/application-services.md). Conflict detection evaluates both the parent and child configuration items \(CIs\) of any CI in scope. A blackout or maintenance schedule applied to an upstream service or CI also captures downstream child CIs that appear in change requests. For the full list of relationships that trigger a conflict, see [Conflict detection](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/it-service-management/change-management/c_ConflictDetection.md). ## Procedure 1. Create a blackout or maintenance schedule.
**Create a blackout schedule** 1. Navigate to **Change** > **Schedules** > **Blackout Schedules**. 2. Select **New**.
**Create a maintenance schedule** 1. Navigate to **Change** > **Schedules** > **Maintenance Schedules**. 2. Select **New**.
2. On the form, fill in the fields.
Field Description
Name Unique name for the schedule.
Description Short description of the schedule.
Time zone Time zone for the schedule.Select **Floating** to evaluate planned start and end dates on the Change Request form for the logged-in user.
Source Source of the blackout or maintenance schedule. Select one of the following options to scope the schedule:- **Service**: Applies the schedule to an application service. The business service must be converted to an application service to be available as a source. - **Change Request**: Applies the schedule to change requests that match the conditions you define. - **CI Class**: Applies the schedule to a configuration item \(CI\) class and its child classes. This option enables the **Applies to** field for selecting the CI class. **Note:** When you select **Service** or **Change Request** from the Source list, the **Applies to** field does not appear. The **Applies to** field appears if you select **CI Class** as the Source, which in turn enables the selection of a **CI Class**.
**Choosing a Source**
When to use each source Use **Service** when the schedule must cover every CI that supports a given application service.Use **Change Request** when the schedule applies to a defined set of change requests rather than to CIs. Use **CI Class** when the schedule applies broadly to a class of CIs and its children. The selected source determines which fields, such as **Applies to**, appear on the form, and how conflict detection evaluates the schedule. For details, see [Conflict detection](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/it-service-management/change-management/c_ConflictDetection.md).
Applies to CI classification that the conflict detection is filtered on. You can select a dynamic CI group. When conflict detection runs, all configuration items in that group are evaluated for blackout and maintenance. The dynamic CI group is seen as the parent CI to all the CIs that are within that group. If there are scheduling conflicts related to any of the CIs in the dynamic group, the conflict is shown in the conflicts table of the dynamic CI group.
Condition Conditions to specify the CIs that the schedule applies to.Use this field to scope a blackout against a set of CIs. For example, all CIs in a class that meet a chosen attribute. This field does not appear when the **Applies to** field is set to **None**. **Note:** Related fields used in conditions are not evaluated for blackout or maintenance schedules.
Category Purpose of the schedule. The available categories depend on the schedule type:- Blackout schedule: **Hard Freeze** or **Soft Freeze** - Maintenance schedule: **Preventive \(measures to improve resilience\)**, **Patching**, or **General** This field is empty by default. The category is stored only after you select a value and save the schedule. When conflict detection generates a conflict record for the schedule, the conflict record includes the category. For descriptions of each category, see [Schedule categories](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/it-service-management/change-management/schedule-categories-reference.md).
Assignment group Group that owns the schedule.
Assigned to User who owns the schedule. This field depends on the **Assignment group** field.
3. Open the form context menu and select **Save**. A blackout or maintenance schedule is created and the Schedule Entries, Child Schedules, and Referenced By related lists appear in the change. **Note:** The Blackout Schedule \[cmn\_schedule\_blackout\] table extends the Condition Schedule \[cmn\_schedule\_condition\] table, which in turn extends the Schedule \[cmn\_schedule\] table. The Blackout Schedule table inherits the domain properties from the Schedule table which has the Domain and Domain path columns. Because the Blackout schedule table uses the same Child Schedule and Schedule Entry tables as the Schedule table uses, the domain support is identical. The **domain\_master** attribute is used to derive the domain from a parent record. For more information, see [Domain support for schedules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-administration/domain-support-for-schedules.md). 4. Create one or more schedule entries. 1. In the Schedule Entries related list of the new maintenance schedule, select **New**. 2. Enter a unique name and define the time during which you want to schedule the maintenance. For more information about the schedule entries field, see [Schedule entry fields](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-administration/r_ScheduleEntryFields.md). **Note:** To delete a blackout or maintenance schedule, open the schedule and select **Delete**.When you delete a schedule, the child schedules and schedule entries associated with it would be deleted. When you delete a schedule, the child schedules and schedule entries associated with it are deleted automatically. 5. **Optional**: Add a child schedule to refine the blackout coverage. 1. In the child schedules related list, select **New**. 2. Define the child schedule for the specific set of CIs or time window you want to add under this blackout. A child schedule inherits from the parent blackout and lets you apply a more specific window to a subset of CIs. ## Result A blackout or maintenance schedule is created. **Important:** Conflict detection evaluates not only the CI explicitly named in a change request, but also its parent and child CIs by walking the relationships defined in the configuration management database \(CMDB\). As a result, a schedule you apply to an upstream business service or CI also covers the downstream CIs associated with that service or CI. For example, a blackout schedule on a payment service captures a change request that targets a database CI that supports that service, because the database is a child of the service. To scope a schedule by CI class and its children, set **Source** to **CI Class** and select a class in the **Applies to** field. The schedule then applies to all CIs in that class and any child classes. ## What to do next Associate the configuration item with the maintenance schedule that is used in the change request. - **[Assign a maintenance schedule to configuration items](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/it-service-management/change-management/use-maintenance-schedule-management.md)** You can review and determine the conflicts in a change schedule by assigning the maintenance schedules to configuration items \(CI\). After you assign a maintenance schedules to the CI, add the CI to the change request. **Parent Topic:**[Conflict detection](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/it-service-management/change-management/c_ConflictDetection.md) **Related topics** [Detect change conflicts]() [Schedule types in conflict detection]() [Configure a change request to monitor outside maintenance schedule conflicts]() [Conflict calendar]() [Enable automatic change conflict detection]() [Detect conflicts manually and review conflict details]() [Define a schedule](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-administration/t_DefineASchedule.md) [Schedule entry fields](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-administration/r_ScheduleEntryFields.md) [Parent and child schedules](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/brazil/markdown/platform-administration/c_ParentAndChildSchedules.md)