Configure conflict analysis properties
- UpdatedAug 1, 2024
- 5 minutes to read
- Xanadu
- Change Management
Configure Change Management conflict analysis properties to detect change conflicts. Use the relevant information to calculate conflicts for change requests and review and modify the change to eliminate conflicts.
Before you begin
Role required: admin
About this task
By default, not all properties are selected in the Change Management Conflict Analysis Properties page. Modify or customize conflict detection capabilities to meet the needs of your organization.
Procedure
- Navigate to .
- In the Change Management Conflict Analysis Properties page, enter the roles that have access to the conflict detection feature.
- Configure the remaining customization properties as required.
- Click Save.
Conflict analysis properties
Conflict detection includes properties that determine how the conflict detection capability is executed. Identify conflicts based on the selected properties and the roles that have access to the feature.
| Property | Property name | Description |
|---|---|---|
| A comma separated list of roles which have access to the conflict detection feature. Roles included here should have access to the underlying change_request record | change.conflict.role | The roles are entered exactly as they appear in . For example, enter itil. |
| When checking for change request conflicts, check against blackout windows | change.conflict.blackout | To check if the change request falls within the blackout window, select Yes. |
| When checking change request conflicts, check whether the change falls within the child CIs' blackout window | change.conflict.relatedchildblackout | To check if the change request of any of the child configuration items (CIs) falls within the blackout window, select Yes. |
| When checking change request conflicts, check whether the change falls within the parent CIs' blackout window | change.conflict.relatedparentblackout | To check if the change request of the parent CI falls within the blackout window, select Yes. |
| When checking change request conflicts, check against changes already schedules for the same CI | change.conflict.currentci | To check if the change request is already scheduled against the given CI, select Yes. |
| When checking change request conflicts, check whether the change falls within the CIs' maintenance window | change.conflict.currentwindow | To check if the change request of the CI falls within the maintenance window, select Yes. |
| When checking change request conflicts, check whether the change falls within child CIs' maintenance window | change.conflict.relatedchildwindow | To check if the change request of any of the child CIs falls within the maintenance window, select Yes. |
| When checking change request conflicts, check whether the change falls within parent CIs' maintenance window | change.conflict.relatedparentwindow | To check if the change request of the parent CI falls within the maintenance window, select Yes. |
| When checking change request conflicts, check whether the change falls within the schedule defined in the maintenance schedule reference field on the CI | change.conflict.ci_maint_sched | To check if the change request falls within the scheduled maintenance defined for the CI in the maintenance schedule reference field, select Yes. |
| When checking change request conflicts, check whether the change falls within maintenance or blackout windows affecting related Application Services | change.conflict.relatedservices | To check if the change request that falls within the maintenance or blackout
windows affects other related application services, such as the services created
that include the CI scheduled for change or any other CI within that service,
select Yes. Note: This action requires any business services
identified to be converted to an application service. For more information, see
Convert business services
to application services.
For information about application services, see Application
services
Application services. |
| When checking change request conflicts, check whether other change requests are already scheduled for the same assigned to user | change.conflict.assigned_to | To check if any other change request is assigned to the same change request assigned to a user. For example, if you assign a change request to a user who is already scheduled to implement another change request at that date and time, a conflict error is displayed, select Yes. |
| CI conflict check mode. Basic mode only checks the change requests CI. Advanced mode checks the entire Affected CIs related list (the change's CI will be automatically added to the related list) | change.conflict.mode | To check the conflict mode for a CI, select the appropriate CI conflict
mode.
|
| Run conflict detection automatically after changes to Configuration item, Planned start date, Planned end date or State when a change request is updated | change.conflict.refresh.conflicts | To refresh and run conflict detection automatically when any of the following
field values are changed, select Yes.
|
| Enable the scheduled change conflict checker | change.conflict.refresh.scheduled | To enable the schedule change conflict checker, select Yes. |
| Automatically include business or application services related to CIs with conflicts in the Impacted CI related list | change.conflict.populateimpactedcis | To automatically include and list all the business and application services with related CIs that have conflicts, select Yes. |
| Identify the most critical business or application service affected when a conflict is detected against a supporting configuration item | change.conflict.identifymostcritical | To identify the most affected business or application services that have a related conflicting CI, select Yes. |
| Define the number of days to be factored after the respective Planned start/end date of a Change record when searching for the next available time. This window is used to find all potentially conflicting Changes, the larger the window, the more Changes that need to be factored per search. Default value is 90 days; the value must be a positive integer. | change.conflict.next_available.schedule_window | To factor from the scheduled planned start date or end date of the change
request to find the next available time, enter the number of days.
|
| Define the number of suggestions to be calculated for the next available time field on a Change. The greater the value, the more time taken to calculate the next available times to implement the change. Default value is 100 suggestions; the value must be a positive integer. | change.conflict.next_available.choice_limit | Enter the number of suggestions to calculate and display for the next
available time.
|
| Logging level for ChangeCheckConflict (default: Notice) | change.conflict.log | Select any of the logging levels for the change conflict.
|
| Handle contiguous change request that has overlapping schedules that results in conflicts. | change.conflict.allow_contiguous_changes | This property is enabled by default. |
| Show message when scheduling conflict is detected. | change.conflict.show_conflict_message | Shows a message when scheduling conflict is detected. Choose any of the given
options to configure the display of the conflict message.
|
| Consolidate conflicts so a conflict is only registered for each unique combination of conflict type and schedule or conflicting-change. | change.conflict.consolidated_conflicts | Displays only the conflicts that results from a unique combination of the
conflict type and schedule or conflict type and conflicting-change. By default, the property is enabled. |
Related Content
- 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. blackout-maintenance-schedule
- Configure a change request to monitor outside maintenance schedule conflicts
When a change request is configured to display the conflicts that are outside the maintenance schedule, conflict detection indicates whether the planned start and end dates occur outside the maintenance window or not. By reviewing the conflicts that are detected, you can modify the change schedule.
- Conflict calendar
The conflict calendar graphically represents the potential scheduling conflicts for a change request. Conflicts are identified as active change requests, blackout schedules, and changes scheduled outside maintenance schedules. Use the Scheduling Assistant to resolve any schedule conflicts.
- Enable automatic change conflict detection
Automate conflict detection to run at specific intervals or when a change request is updated to immediately review the conflicts when the schedule dates are updated.
- Detect conflicts manually and review conflict details
Run conflict detection manually for a change request and cancel conflict detection before it completes. Review the conflicts detected either automatically or manually and resolve them by changing the schedules.
- Conflict analysis properties
Conflict detection includes properties that determine how the conflict detection capability is executed. Identify conflicts based on the selected properties and the roles that have access to the feature.