This documentation supports the 25.1 version of BMC Helix Change Management.To view an earlier version, select the version from the Product version menu.

Relating items to the change request

You can relate items such as outages, incidents, infrastructure changes, known errors, and configuration items to a change request. You relate only those items to a change request that are affected by the change request. For example, you create a change request to format the assets in your organization. In this change request, you relate all the assets that need to be formatted. When you relate an item to a change request, all of its related items are also automatically related to the change request. For example, when you relate an outage to a change request, all the configuration items that relate to the outage are also automatically related to the change request.

You can create a change request that affects the assets or CIs of your organization. When the change request affects the assets of your organization, you can relate these assets to the change request. For example, when you create a change request to format machines, you relate all those machines to the change request. 

When defining a relationship between a CI and a change request, the following options are available:

  • Related to—Relates the item or request to the change request.
  • Upgrades—Upgrades the item or items as part of the change request process.
  • Repairs—Repairs the items or items as part of the change request process.
  • Impacts—Impacts the item as part of the change request process.
  • Moves—Moves an item from one location to another location as part of the change request process.
  • Installs—Installs the item as part of the change request process.
  • Removes—Removes an item from the location as part the change request process.
  • Changes—Changes items as part of the change request process.

These options are for information purpose, which can be used while reporting based on the organizational requirements and processes.


To relate items to a change request

  1. On the Related Items tab for a change request, or release requests, click Relate existing item.
  2. Specify the related item type, such as Infrastructure change, Work Order, Incident, or Outage.
    (For BMC Helix ITSM: Smart ITonly) When you relate an existing outage to a change request, some filters are applied by default. For example, the system searches for scheduled outages for CIs related to the change request. If you want to search for other outages or for all outages, clear the default filters and add new filters as needed.
  3. Specify search criteria and initiate the search.
    You must specify some search criteria, such as a company name, status value, or keyword. To search for all records, enter the % wildcard character.
  4. Select related items and specify the relationship type.
  5. Click Save.
    The related items are displayed on the Related Items tab. You can view only those items to which you have access. if you click an item to which you do not have access, an error is displayed.

To relate CIs to change requests

  1. Open an existing change request.
  2. On the Configuration items tab, click Relate configuration item to add a related configuration item.
    To relate multiple CIs to the change request, you can search for multiple CIs by using commas to separate them. Select the required search results and click Add.
  3. In the Add configuration items (CIs) window, click Advanced to select the required Filters and Presets.

    Add configuration items_Advanced.jpg
  4. Click Apply filters and then click Save.
    The filters are displayed under the active link on the Activity tab.

  5. Search and select the required CI.

    Important

    You can select only 20 CIs when relating CIs to a change request. Click Select all CIs on page to perform this action.

  6. Select the Association type from the following options:
    • Changes
    • Impacts
    • Installs
    • Moves
    • Related to
    • Removes
    • Repairs
  7. Click Add.

The configuration item is related to the change request.

To edit an outage record

An outage is a downtime of an asset or a CI.  An outage can be scheduled or unscheduled. Sometimes, after you create the outage record, you might have to make changes to the schedule of the outage. In BMC Helix ITSM, you can make changes to the outage schedule directly in the ticket instead of making changes for each CI by opening the asset form. For example, you create a change request to install the latest anti-virus software on all the laptops in the IT department on a Friday. But you have been requested to install the anti-virus software on a non-working day to avoid an outage on a working day. You can update the availability details of all the laptops at a time in the change request, instead of searching for each laptop from the asset form and updating the availability details. You must have either Asset Admin or Asset User permission to edit an outage. For more information, see Asset Management user roles and permissions.

  1. Open an existing ticket. For example, open a change request.
  2. Click the Related items tab.
  3. Click the ID of the outage in which the Status field is set to Scheduled.
    image-2023-5-3_10-12-38.png
    You can edit an outage only if its Status is set to Scheduled.
  4. In Edit outage, edit the fields that you want to change. For example, there is a change in the availability of the asset that relates to the change request. So, you edit Scheduled start date+ and Scheduled End date+.
    image-2023-5-3_10-14-28.png
  5. Click Save.

To relate impacted services and CIs to the change request

After the impact analysis is completed, you can relate the impacted CIs to the change request or discard the results. CIs found during the impact analysis are shown in a list format with the most impacted services at the top, up to a total of 100 services and CIs. You can select individual services and CIs, or you can select all services or all CIs and relate them to the change request.

The Initiate Impact Analysis option is unavailable if the impact analysis is in progress. If you want to stop an impact analysis that is in progress, use the Abort option. The Abort option is available when the impact analysis is in progress.

  1. Open a change request.

  2. Click More > Initiate Impact Analysis.

    Tip

    If you want to perform other tasks on other screens while the impact analysis runs, click Close in the Impacted CIs dialog box. You can open the Impacted CIs dialog box later to view the impact analysis results by opening the change request and clicking Show more on the impact analysis status message.

    ChangeImpactAnalysisBanner.png

  3. In the Impacted CIs dialog box, on the List view tab, select the CIs you want to relate.
    AsyncImpactAnalysis_False.png
  4. Click Relate.
  5. On the confirmation message, click Yes.

To exclude CIs with a Delete status from your search

You can search for CIs that are in Delete status from change requests. If you do not want the system to search for CIs in Delete status, you must select the check boxes for the statuses that you want to search, and clear the Delete check box. By default, in the search result the system displays CIs in all statuses including the Delete status.

To restore a CI that is in Delete status, when you create or edit change requests, on the CI tab, perform the advanced search and select the Delete check box to search for CIs in Delete status. From the search result, relate the change request with multiple CIs that are in Delete status to track configuration changes made to the CIs.

To create a related item

  1. On the Related Items tab for the incident, work order, problem, known error, or change request, create a related ticket, such as a Related Incident or Related Work Order. For an incident or a change request, you can also create a Related Outage. In PWA screens, for a change request, you can use a template to create a related change request.
    A new ticket opens in draft mode with some information pre-populated from the original ticket. Outages created from change requests require specific information.
  2. Update the new item as needed and save it.
    Relationships between the items appear in Related Items. The original ticket has a Created relationship that links to the new item, and the new item has a Created by relationship that links to the original ticket.
    In Smart IT, if you select Relationship type as Duplicate of when relating an incident to another, you can select only one incident in the table. However, in Progressive Web App incident screens, when you relate an existing incident as a duplicate, you can select multiple incidents but on clicking Save, you are asked to specify an incident only.

Information copied to a related ticket

The following minimum information is copied to the related incident, problem, known error, work order, or change request:

  • Customer and Customer Company
  • Summary
  • Notes
  • Affected Service
  • Priority


Instructions for classic interfaces


View instructions for classic Smart IT

To edit an outage record

  1. Open an existing ticket. For example, open a change request.
  2. Click on the Related Items tab.
    image-2023-4-25_12-14-18.png
  3. Select the the outage record that you want to edit and click Edit.
  4. Edit the fields that you want to change. For example, there is a change in the availability of the asset that relates to the change request. So, you edit Scheduled start date+ and Scheduled End date+.
  5. Click Save.

To relate impacted services and CIs to the change request

After the impact analysis is completed, you can relate the impacted CIs to the change request or to discard the results. CIs found during the impact analysis are shown in a list format with the most impacted services at the top, up to a total of 100 services and CIs. You can select individual services and CIs, or you can select all services or all CIs and relate them to the change request.

Click Relate All from the alert on the change request to relate all services and CIs to the change request without viewing the results, as shown in the following figure:

relate all from alert.png

Alternatively, click Conduct Impact Analysis from the alert to display the impact analysis results in graphical format. The graph displays all CIs and services that are related to the change request at the top, as starting nodes. Impacted CIs and services at the end of the relationship chain are shown along the bottom. Impacted services and CIs in the middle of the relationship chain are shown in blue boxes that you can expand or collapse by double-clicking, or by using the Expand all and Collapse all buttons near the top of the display.

You can open the Icon Guide in the universal client to view descriptions of the icons used for different types of CIs in the impact analysis.

icon guide.png

Click each service or CI individually to select it. Optionally, select the Box Selection control and drag your mouse over a group of CIs and services to mark all of them as selected. Click Clear Selection to deselect all services and CIs. You can use various display options to explore the impacted services and CIs. For example, you can zoom in and out, toggle to full screen mode, choose portrait or landscape layout, or manually drag CIs on the screen to optimize the view. Click the Recenter icon to restore the original display after zooming or manually dragging CIs.

box selection.png

Select Relate All at the bottom of the display to relate all impacted services, CIs, or both to the change request. For individually selected services and CIs, click Relate Selected.

select cis and services.png


View instructions for Mid Tier

To unrelate CIs from change requests

  1. In the Show Related field on the Relationships tab of the Change form, select Configuration Item.
  2. Select the required configuration item to unrelate, and then click Remove.

To view configuration items related to a change request

You can view the configuration information from the Relationships tab of the Change form.

Select the configuration item from the Show Related list, and then click View. The Asset Management Configuration Information form appears that displays the details of the configuration.

Important

You cannot define a new configuration item on the Relationships tab. Use the Functions > Manage CIs on the Change Management console to define new CIs. For more information, see Creating-a-CI.

To view the impact of CIs on change requests

You can relate configuration items to change requests, based on a simulated impact analysis generated by the Atrium Impact Simulator tool. Additional workflow in Change Management lets you use Atrium Impact Simulator functionality to predict how a change to the availability of a CI affects other CIs and services. For example, you could run a simulation in Atrium Impact Simulator to learn what devices and applications in the network are affected if you take a specific server offline due to scheduled maintenance or lease returns.

Atrium Impact Simulator is transparently integrated into other BMC applications as an integral part of their workflow. From Change Management, Atrium Impact Simulator exposes only the features required for the user, simplifying the user experience. For more information, see Atrium Impact Simulator analysis for change requests.

Important

The Impact Analysis functionality is not available on the Relationships tab of the Release form.

  1. Open the change request, and then click the Relationships tab.
  2. Relate at least one CI to the request.
    You can layer multiple requests for different types of CIs and add to the impacted list. You can use any Relationship Type except Impacts.

  3. In the Relationships tab, click Impact Analysis.

    Important

    The Impact Analysis button is enabled only for CIs that belong to Production Data Set (PDS). For more information on PDS, see Relating CIs to alternate datasets.

    The Atrium Impact Simulator opens.

    Impact Simulation_Results in table_20.02.01.jpg

  4. Click Simulate Impact to run the simulation.
    In the Simulation Progress dialog box, you can click the Cancel button to stop a long running simulation (if needed).
  5. Click the Results in Table tab.
    A list of impacted CIs are listed and also the number of results is displayed in the header bar.

  6. To relate the results to the change request, you can perform the following actions:

    Important

    Running an impact simulation does not relate the results automatically to the change record. You must click Execute to select the results that should be related.

    Action

    Result

    Set the Relate column to Yes or No.

    By default, the change results are defaulted to Yes to relate. Using the Relate column, you can individual toggle the action to No or Yes for granular control. These can be set as a group, by using the Execute option.

    Show Only Services (click to toggle)

    Lists only the impacted service CIs in the view.

    This action has no effect on relating.

    Show All Results (click to toggle)

    Lists all the impacted CIs in the view.

    This action has no effect on relating.

    Pick list and Execute button

    Modifies the relate options. They provide a quick way to select groups of CIs to relate or unrelate. You can select from the following options:

    • Relate All—Relates all CIs and services from the change request.
    • Unrelate All—Unrelates all CIs and services from the change request.
    • Relate All Services—Relates only services to the change request.
    • Unrelate All Services—Unrelates only services from the change request.
    • Relate Selected—Based on the CIs or services you pick, relates them to the change request.
    • Unrelate Selected—Based on the CIs or services you pick, unrelates them from the change request.

    Click Report

    Runs a report that exports all the fields in the simulation. This report can export all fields that are in the new .csv file or any subset of them.

    The report file, which is attached to the change request, provides a history that can be referenced in the future.

    Click Cancel

    Exits the window without make any changes.

  7. Click Save to create the CI relationship between the change request and the selected CIs.
    The CIs are now displayed in the Relationships tab. Work information is created for the change request with the attached simulation .csv file.

    Important

    The hour glass icon on the Atrium Impact Simulator keeps spinning even if the impact stimulation is completed. In this case, you need to click the hour glass icon on the screen to stop it.

  8. Click Close. 

To view CI relationships by using BMC Atrium Explorer

BMC Atrium Explorer displays configuration items (CIs) and their relationships to other CIs within CMDB, thereby enabling you to improve the accuracy of change planning by locating the CI. For more information, seeExploring asset relationships in the Asset Management documentation or Working with CIs and relationships in the CMDB online documentation.

  1. On the Change form, select Functions > Time Segments > Configuration Item (CI).
  2. In the CI Advanced Search dialog box, search for a CI.
  3. From the CI Search Results table, select a CI, and then click Explore CI.
  4. From the list of related CIs that are displayed, select the filter to limit the data that is displayed in the relationship viewer. 
    The relationship image is reloaded with the selected data.

To relate CIs from alternate datasets

When you open the Change form, different datasets are available when relating CIs to a change request:

  • Personal Preference Change Data Set (CDS)—When you open the Change form, the personal preference change dataset is loaded as a global setting from your application preference settings. If this setting is blank, the production dataset is loaded from the AST:AppSettings form. For more information, see Setting-application-preferences-and-options.
  • Production Data Set (PDS)—If there is no CDS, the PDS is loaded as the global setting. The PDS value is taken from the Dataset field on the AST:AppSettings form.

  • Alternate Data Set (ADS)—Field on the Change form on the Relationships tab that enables you to select a different dataset other than the CDS or PDS.

    Important

    For more information about datasets, see To configure Asset management settings in the Asset Management documentation.

You must understand the following restrictions if you use an alternate dataset when relating CIs:

Configuration items

Alternate Data Set field

Dataset preference

Result

If there are no CIs related to the change

Empty

CDS

You can select the Alternate Data Set as needed. After you start working on the change request, the setting of the ADS is the dataset that you selected last.

If there are no CIs related to the change

Empty

PDS

Production Data Set is used.

Important: An empty Alternate Data Set field is equivalent to using the Production Data Set.

If CIs are related to the change

Selected

Not applicable

Alternate Data Set field is locked. If you relate a CI with the Alternate Data Set, you must save the change to save the Alternate Data Set.

Important: There is no database rollback on the relationships.

If all related CIs are removed

Editable

Whatever the last value is

When all the related CIs are removed, the Alternate Data Set field becomes editable. If you clear the Alternate Data Set field when it is editable, the dataset is Production Data Set.

Important

  • The CDS is the default value, and is used only if ADS is set to CDS when you relate a CI. If you choose PDS, you must clear the Alternate Data Set field.
  • When the status of the change request moves to Closed, the change is locked for everyone except the change master. Only the change master can make modifications to a change request in the Closed status, including adding and removing relationships. For the change master, the Alternate Data Set field behaves the same way as when the relationship is not locked.
  1. In the Relationships tab, select a dataset from the Alternate Data Set list, for example, BMC Asset.
    Depending on the applications installed, you might see the following options:
    • BMC Asset
    • BMC Configuration Import
    • BMC Sample Dataset
    • BMC.ASSET.SANDBOX 
      alternate-dataset_61516_516.gif
  2. From the the CI Relationships Search dialog box, search for and relate CIs from the alternate dataset.

  3. Save the change request.

To define CI unavailability

You can define CI unavailability entries only if Asset Management is installed. CI unavailability entries track down time of an outage against a CI. For example, CI unavailability can be an outage due to scheduled maintenance, usually through a scheduled change. Also, CI unavailability can occur due to an unexpected circumstance, usually related to an incident.

When you save the CI unavailability entry, the CI unavailability relationship entry is generated, which is displayed on the Relationships tab.

Important

CI unavailability cannot be tracked directly against CI components. The Relate with Unavailability button does not appear on the CI Relationships Search form when you are searching for CIs from a release request.

To relate an unavailable CI to a change request

Typically, change requests occur because a CI needs to be upgraded (such as an operating system) or needs repair (such as a server). By Using Change Management, you can relate unavailable CIs (also known as outage records) to their related change request. By relating an unavailable CI record to a change request, you can track its history, and the costs related to changes to the CI.

  1. Open a change request, and then click the Relationships tab.
    If unavailable CIs are related to the change request, they appear in the Relationships table.
  2. From the Request Type list, select CI unavailability, and then click Search.
  3. In the CI Unavailability Search form, enter search parameters to filter the CI relationships shown, and then click Search.
    The quick search buttons enable you to easily filter CI unavailability with different criteria:
    • All unavailability
    • All scheduled unavailability
    • All unscheduled unavailability
  4. Select an unavailable record from the list.
  5. From the Relationship Type list, select Related to, and then click Relate.
    The following actions occur:
    • Messages alert you that the CI has been automatically related to the change.
    • The CI Relationships Search form closes.
    • The unavailable CI and its related CI record appear in the Relationships table.
  6. If needed, you can broadcast the CI unavailability.
    For more information, see Performing additional functions with CI unavailability.

To relate a change request to a CI with unavailability

  1. Open a change request, and then click the Relationships tab.
    The Relationships tab displays the requests that you can relate to the change.
  2. From the Request Type field, select Configuration Item, and then click Search.
  3. On the CI Relationships Search form, complete the search criteria tabs with the relevant information, and then click Search.
  4. In the Relationship Type field, select the type to relate with the change request, for example, Related to.
  5. (Optional) Click Explore CI to view a CI and its relationship in BMC Atrium Explorer.
  6. Click Relate with Unavailability.
    If the CI has open unavailability entries created against it, the CI Unavailability Exist dialog box appears.
  7. Enter the unavailability settings (for example, Scheduled Full and the scheduled start and end dates), and then click Save.
    For information about filling out this dialog box, see Relating unavailable CIs.
  8. Close the CI Relationships Search dialog box.
    The CI unavailability request type appears in the Relationships table.

To create CI unavailability where other CI unavailability already exists

  1. Select the associated Configuration Item from the Relationships table.
  2. From the Quick Actions menu, select Create New CI Unavailability, and then click Execute.
  3. Perform one of the following procedures:
    1. If the CI has open unavailability entries created against it, the Existing Configuration Item Unavailability dialog box is displayed.
      Perform one of the following actions:
      1. Click Create New to define an unavailability entry. You are then prompted to define the configuration item unavailability, for example, unscheduled full unavailability type, start and end dates.
      2. Select an entry from the table, and then click Relate to Current Request to relate the change directly against the CI unavailability entry. You are then prompted to specify the relationship type between the current request and the selected CI unavailability.
    2. If the CI does not have any unavailable CI entries, the Configuration Item Unavailability dialog box is displayed.
      1. Select the unavailability type that best describes the down time (for example, Scheduled Full).
      2. Enter the appropriate Scheduled Start and Schedule End dates.
      3. Enter remaining information, as needed.
      4. Click Save.
  4. Save the request.

To create CI unavailability from CIs associated with a request

If you have installed Asset Management, you can also define CI unavailability entries after the CI has been associated with the change request (or release request).

  1. Select the associated CI from the Relationships table.
  2. From the Quick Actions menu, select Create New CI Unavailability, and then click Execute.
    In the Configuration Item Unavailability form, the Unavailability Class default value is Change. Enter specific details, for example, unscheduled full unavailability type, the actual start date, or the assignment status.
  3. Select the unavailability type that best describes the downtime.
    The options are as follows:
    • Scheduled Full— You plan to take the CI out of service during a scheduled change.
    • Scheduled Partial— You plan to change the CI, but not take it out of service.
    • Unscheduled Full— The CI is experiencing an unplanned complete service outage.

    • Unscheduled Partial—The CI is experiencing an unplanned service degradation.

      Important

      After you select the unavailability class and type, the Priority field is filled based on a configurable CI Unavailability Prioritization mapping.

  4. (Optional) Modify the description identifying the reason why this unavailability is being defined.

  5. Enter the appropriate Scheduled Start Date and Schedule End Date.
    After you enter the dates into these fields, the system automatically calculates the Estimated Duration.

    Important

    When a Scheduled Start Date is entered without an Actual Start Date, the Unavailability Status is automatically set to Scheduled.

  6. Enter the Actual Start Date and Actual End Date, as required.
    The system automatically calculates the Actual Duration, based on the actual dates.

    Important

    When an Actual Start Date is entered without an Actual End Date, the Unavailability Status is automatically set to Current Unavailability. The Unavailability Status is automatically set to Restored when the Actual End Date is filled in. After the Actual End Date is set, you can modify it, but not delete it.

  7. Select where the assignment is set from.
    The Assignment is set from field determines where the assignment is based.
    • Configuration Item—Automatically assigns the CI unavailability entry, if an assignment record has been defined for unavailability from within the Configuration Item Contact relationship.
      This type of assignment can be configured to be locked or open.
      Locked means that the system selects the Assignment Group from the Configuration Item Contact relationship, and then locks the fields so that they cannot be re-assigned or manually overridden.
      Open means that the system selects the Assignment Group from the Configuration Item Contact Association and then enables you to select another assignment method.
    • Cross Referenced Request—Assigns the CI unavailability entry when the CI unavailability is generated from either an infrastructure change or an incident. This setting keeps the CI unavailability assignment synchronized with either the change or the incident record assignment.
    • Manually—Lets you assign the CI unavailability entry manually to any group defined within the application.
    • Automated Routing—Automatically assigns the CI unavailability entry to a support group, if you do not assign a support group from the People tab. Automated routing is configured by using the CFG:Assignment configuration form. 
      For more information about configuring BMC Helix ITSM, see Setting up and going live.
  8. If you selected Manual assignment, set the assignment company, organization, group, and assignee.
    The individual or group assigned to this unavailability record must set the status to Completed after recording the actual start and end times.

  9. Set the Assignment Status to Assigned.

    Important

    The Assignment Status governs whether the CI unavailability entry is considered Open or Closed. Setting the Assignment Status to Completed marks the CI unavailability entry as closed.

  10. (Optional) Click Set From Change Schedule to retrieve the request's scheduled start and end dates and times.
    You can use this button to fill the Schedule Start and End date and times on the CI unavailability record. This feature is available only for those CI unavailability records that were generated from a change request (not release requests).
  11. (Optional) Click the CI Status Information tab to change the status of the CI, for example, In Repair.
  12. (Optional) Click the Relationships tab to see possible relationships against the unavailability that might exist, for example, relationships to incidents, changes, or problems.
    You can also define relationships to these respective modules.

  13. (Optional) Click the Financials tab to define cost entries against the unavailability.
    This enables you to track costs associated to the down time.

    Important

    You must save the CI unavailability record before you can define Relationships and Financials.

  14. (Optional) Click the References tab to view the record identification numbers for any incidents or changes that might have created the unavailability entry.
  15. (Optional) Click the SLM tab to see the service targets and milestones for the restoration of the unavailability. Service targets and milestones are defined from within BMC Service Level Management. Escalations can be defined to notify the assignment group prior to acknowledgment or resolution breach times.
  16. Click Save to define the new CI unavailability for the record.

To perform additional functions with CI unavailability

You can perform the following additional functions with CI unavailability.

To modify CI unavailability

  1. On the Relationships tab of the Change form, select the unavailability entry to modify.
  2. Click View.
  3. On the Configuration Item Unavailability form, modify the information as required.
  4. Click Save.
  5. To create a financial cost for the unavailability, click Add on the Financials tab of the Configuration Item and in the Costs dialog box, enter the required information as required.

  6. Click Save.

    Important

    The CI unavailability entry represents the entry as seen within the CI unavailability form. The CI unavailability entry that appears on the Relationships tab represents the relationship between the unavailability and the change.

To modify outage information

  1. From the Change form, select Functions > Outage List.
  2. On the CI Unavailability form, modify the information as required.
  3. Click Save.

For more information, see Managing outages.

To delete CI unavailability

  1. On the Relationships tab of the Change form, select the unavailability entry that you want to delete.

  2. Click Remove.

    Important

    Deleting a CI unavailability entry also deletes all the related relationships and cost entries against the unavailability. The CI unavailability is deleted if the cross-referenced ID is the change ID.

To broadcast CI unavailability

Important

You must have the Broadcast Submitter functional role to broadcast the current change.

  1. On the Relationships tab of the Change form, select the unavailability entry to broadcast.
  2. From the Quick Actions menu, select Broadcast CI Unavailability, and then click Execute.
  3. On the New/Modify Broadcasts dialog box, complete the required fields and any other information.
  4. Click Save.
    The View Access field is used to make the broadcast available on the web (if your Broadcast form is web-enabled and the View Access is set to Public).

To define a dependent change request with a sequence number

When you create change requests, you should specify the sequence in which change requests are to be completed. When you specify a sequence for the dependent change requests, you must complete a change request with the sequence number 0 before you can start a change request with the sequence number 1.

In the following example, you have two related change requests. The change request to update the I/O device software has dependent relationships to two other change requests.

Important

You cannot assign sequence numbers to release requests.

  1. Open the change request to upgrade the operating system, and then click the Relationships tab.
  2. Select the dependent change request from the Relationships table.
    The default sequence number for the dependent change request is 0.
  3. Click View.
  4. In the dependent change request, click the Relationships tab.
  5. In the Sequence field, enter a number (for example, 1).
    The sequence number indicates the order in which the dependent change request must be completed relative to the original change request.
  6. (Optional) If necessary, add any additional information about the Change form to finish relating the change request.
  7. Save your work, and then close the change request.
    You return to the original change request.
  8. To view the updated sequence number, refresh the table.
    The record now shows a sequence of 1. The sequence number indicates the order in which you must complete the current request relative to the dependent request. In this example, you must now complete the change request (sequence 1) to remove the old software before you can start work on installing the new software (sequence 2).
  9. Save the change request.

To define a change request related to another change request, with no dependency

When you work with a change or release, you might need to define another related change request. For example, you might need to define related change requests that address similar problems. A set of related change requests can result from many changes needed by one requester at the same time.

For a release request, a related change is a manifest included within the release. For information about creating a change request related to a release request, see Creating a release manifest.

  1. Open the change request, and then click the Relationships tab.
  2. Select the entry from the Relationships table.

  3. From the Quick Actions list, select Create Related Request > Infrastructure Change.
    In the Change form, fill in the details on the Change form as described in Creating-change-requests-in-the-Initiation-and-Recording-stage.

    Important

    If you want to create the related change request by using a change template, then you must first apply the template and then create the relationship. The relationship is not created if this sequence is not followed.

  4. Click Save.
  5. Return to the original change request by using the breadcrumb bar.
  6. Save the original change request.

To relate a change request to another change request

When you work with a change request, you might also need to relate another change request to it. Relating change requests enables the support staff to work with multiple change requests for the same requester at once. With related change requests, you can optionally designate if the current change request exists in a dependent relationship to a change request.

  1. Open the change request, and then click the Relationships tab.
  2. Select the entry from the Relationships table.
  3. In the Request Type field, select Infrastructure Change, and then click Search.
  4. In the Change Relationship Search form, use the various tabs to choose the appropriate search criteria.
  5. To use more specific search criteria, click the Advanced Search tab, enter the appropriate search criteria, and then click Search.
  6. In the Change Results table, select the item to relate.
  7. In the Relationship Type field, select how to relate the current request to the selected change request.
    • Related To indicates the two changes are related to each other.
    • Dependent indicates the current change request depends on the original change. Dependent changes can be assigned sequence numbers to specify the sequence in which the dependent change requests should be completed.
  8. Click Relate, and then click OK.
    If you create a dependent relationship, the sequence appears in the Relationships table.
  9. Save the change request.

To remove a related change request

This procedure removes the change request from the relationship with another change request. It does not delete any change requests.

  1. Open the change request in the Change form, and then click the Relationships tab.
  2. Select the request to unrelate, and then click the Remove icon.
  3. Save the change request.

To view change dependencies

  1. Open the change request in the Change form, and then click the Relationships tab.
  2. In the Show Related field, select Infrastructure Change.
    A list of change requests appears in the table. Changes with a dependent relationship to the current request are shown as Dependent under the Relationship Type column. The table shows the status of each request for you to monitor the progress of the change request implementation.
  3. To view a request, select it, and then click View.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*