This documentation applies to the 8.1 version of Change Management, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Collision detection overview

A collision occurs when a CI is related to two or more change requests whose implementation schedules overlap. BMC Change Management detects collisions between change requests automatically, and helps you to make decisions to manage and resolve the potentially harmful conflicts between these change requests. 

This topic provides the following information:

How collisions occur

Understanding how collisions occur helps you to to avoid spending resources inefficiently, and to avoid creating instability in your IT infrastructure. Collisions are dependent upon a time (scheduling) factor and a CI factor. Both factors, together, play a role in determining whether a collision exists.

Time factor

The time factor of collisions is dependent upon the Scheduled Start Date and Scheduled End Date values in the Date/System tab of change requests. Collisions occur when there is a complete or a partial overlap of implementation schedules. If you consider two change requests, A and B, the following schedule-based collision scenarios are possible:

  • Identical dates—Both change requests have the same scheduled start and end date values. It is unlikely that the CI will be available for two IT personnel to work on at the same time.
  • Complete schedule overlap—Work on change request B is scheduled to begin after work on change request A, but will be completed before the work on change request A is completed. In this scenario, even though change request B requires a shorter implementation period, the CI will be unavailable to the assigned IT personnel because of the work being done for change request A.
  • Start date and end date overlap—Work on change request B is scheduled to begin before work on change request A is completed. In this scenario, the IT personnel assigned to work on change request B will not be able to access the CI because work on change request A is still in progress.

CI factor

The CI factor determines the risk that the implementation of a change request might impede or undo the implementation of another change request. Depending on the type of effect that a change request has on a CI, the following CI relationship-based collision scenarios are possible:

  • Direct effect—A CI is related to two or more change requests. All of the change requests affect the CI directly, and have overlapping schedules.
  • Indirect effect—A CI that has dependencies is related to a single change request. This change request is likely to affect the dependent CIs indirectly. If one of the dependent CIs is related to a different change request with a conflicting schedule, a collision occurs between the two change requests. For Atrium Impact Simulator to detect collisions caused indirectly related CIs, the CI affecting the change request, should be related to the Change, and the Atrium Impact Simulator should be run after this is done.


Consider a server that hosts a number of virtual machines. User A submits a change request for an operating system upgrade on one of the virtual machines. The request is scheduled to be implemented between 4:00 P.M. and 5:00 P.M. on Tuesday, the following week. The next day, User B submits a change request to add another hard disk to the server. This request is also scheduled to be implemented on Tuesday of the following week, but between 3:00 P.M. and 6:00 P.M.

A collision now exists, because of the complete schedule overlap, and because the change request for the server hardware upgrade indirectly affects the virtual machines that it hosts. A change in schedule is necessary to implement both change requests efficiently.

For the Atrium Impact Simulator to detect the collision caused due to the indirect effect of the hard disk change to the virtual machines, User B must relate the hard disk CI to the change request he created, and run the Atrium Impact Simulator, so that the collisions caused by the new hard disk are detected.

How collision detection works

Collision detection works by automatically comparing CIs that are listed on the Relationships tab of change requests. CIs that are related to change requests from the Service field are also displayed on the Relationships tab, and are included in the comparison. Additionally, the Scheduled Start Date and Scheduled End Date values of change requests are compared to determine whether their implementation periods overlap. For more information, see How collisions occur.


BMC recommends that you run an impact simulation in BMC Atrium Impact Simulator to detect CI dependencies before you use Collision Detection. Saving the simulation automatically relates all dependent CIs to your change request, which ensures that any collisions are detected. For more information, see Viewing the impact of CIs on change requests.

The Collision Detection link in the Functions menu of the Change form indicates the collision status of CIs related to the change request. The collision status is indicated by one of the following link colors:

  • RedAt least one collision is in the Detected or Investigating state. Clicking this link opens the Collision Detection dialog box, where you can view the collisions that affect a particular change request.
  • BlackNo new collisions have been detected. Either no collisions exist, or all collisions are in the Ignored or Resolved state.

For more information about collision states and the Collision Detection dialog box, see Using Collision Detection.


The following differences exist in the way that Collision Detection works in release requests:

  • Collision Detection is run against the changes in the release manifest, not the changes that are related to the release on the Relationships tab. Collision Detection does not apply to release activities in the release manifest.
  • The Collision Detection link does not turn red when a collision is detected.
  • You fix collisions on the Manifest tab of the release form.

Related topics

Using Collision Detection 
Viewing the impact of CIs on change requests 

Was this page helpful? Yes No Submitting... Thank you