This documentation supports the 21.05 version of BMC Helix ITSM: Change Management. To view an earlier version, select the version from the product version menu.

Creating a release request

You can create a release request at the Initiate stage.

To create a release request at the Initiate milestone

  1. Review the request for changes (RFCs) to make sure you understand their requirements.
    Perform this manual step before you open Release Management. Make sure you understand the scheduled start and end dates, the CIs involved, the manifests necessary to complete the release, the CAB approvers, and so on.

    Best practice

    Enter information into Release Management as soon as it is available to you. You can revise it at later milestones.

  2. On the Release Management Console, click Create to open the Release form.
    The Release ID field is filled automatically with an ID number for the release request.
    In the Initiate stage, the release request initially appears in Draft status.
  3. Use the following fields to specify the release coordinator:
    • Coordinator Group—Specify the group of people with the Release Coordinator functional role. This list is populated with groups that have at least one user with a Release Coordinator functional role.
    • Coordinator—Specify the user responsible for the release. The list is populated with people with the Release Coordinator functional role and who are included in the selected Coordinator Group.
  4. From the Service field, select the business service configuration item (CI) that relates to the release request that you are creating.
    The Service field relates business service configuration items (CIs) to the release request at the time it is created. 


    The business service CI is not a physical CI (such as a printer or a router); it is a logical CI. In this context, a logical CI is a business service that can be provided from one business or organization within a business, to another. Service CIs can include customer support, employee provisioning, web farms, and storage. When business service CIs are created and made available on the Service field menu, they are either related directly to the customer or related to the customer's company, organization, or department. If you need to have a new business service CI added to the Service field menu, you must notify a system administrator with Asset Administrator privileges.

  5. (Optional) Select a template to complete a part of the release request.
    Release templates are especially useful in any release request that follows well-defined methods for specific and repeated requirements. Release templates do more than simply fill out fields for you; they can also include CIs and manifests to the release request. The template is attached to the release request.


    The release template can be applied in the Draft state, that is, while creating the release request.

    If you start to enter fields in the release request and then select a release template, the release template overwrites any field values that are already present in the release request. Any relationships or manifests included with the release request are not overwritten. Any additional manifests from the template are added as peers, and additional relationships (for example, CIs) are included with the release request.

  6. (Optional) Specify the target date as the date by when the release must be completed, according to the applicable service level target or specify the target date that is agreed to on an ad hoc basis.
  7. Complete the following fields:




    Provide a brief description of the release.

    Business Justification

    Specify the business requirement for the request. Select an option based on the policies defined by your company. These values are for informational purpose only. You have the following options:

    • Corporate Strategic
    • Business Unit Strategic
    • Maintenance
    • Defect
    • Upgrade
    • Enhancement
    • Customer Commitment
    • Sarbanes-Oxley


    Specify the extent to which the release affects the business. The default value is 4-Minor/Localized.

    Impact is often directly related to the extent to which the service has degraded from the agreed service levels. Impact can be measured by the number of people affected, the criticality of the affected system, and the loss of revenue as a result of the service degradation or disruption.


    Specify a value that indicates the importance of the release request, and reflects how quickly a release must be implemented, or the time available to reduce the impact of the release on the business. The default value is Low.

    Use the following factors to determine Impact and Urgency:

    • Number of customers affected by associated releases.
    • Duration and scope of the service disruption.
    • Availability of a solution or workaround.
    • Type of service being disrupted, usually based on the involved CI.
    • Awareness of the future impact on the business.


    (Optional) Specify the importance that you (as support staff) assign to the release request.

    Priority indicates the relative order in which to address the releases. It is influenced by considerations of risk and resource availability, but is primarily driven by the combination of Urgency and Impact. The default value is Low.

  8. Select the Risk Level to indicate the relative risk associated with the release.
    The default risk level is Level 1, which is the lowest level. The highest risk level is Level 5. The Risk Level is used as a criteria to determine the required approvals.
    For more information about how to configure or modify the Impact, Urgency, and Priority data so that it is set automatically, see Computing risk levels.

  9. Select the Release Type to further categorize the release request.




    All components of the release are built, tested, and deployed together. You can use the Full release type if you want to make sure that the release or version of your application, plus the necessary CI components to run the application, are all linked throughout the entire process.


    This option includes only incremental releases and only those components or CIs that need to be included in this release. You can use the Delta release type if your application is moving from version 1.0.00 to 1.1.00, for example.


    All individual Full and Delta releases are grouped together to form a packaged release. You can use the Package release type to you combine several minor and major updates together.


    This option identifies and reviews multiple changes, incidents, and problems that are candidates to target the release implementation. The Backlog release type is a grouping mechanism that the CAB uses as their candidates to review the future releases.


    Do not manually set the Milestone, Status, and Status Reason fields in the Release form.
    When you use the Process Flow Status bar to move the release request to the next milestone, the value in the Status field automatically changes, based on the options you select from the Status bar menus.

  10. Click Save to create the release request.
    This information is the minimum information needed to create the release.

To specify the business justification

At the Initiate milestone, the release coordinator prepares a business case to justify the release, for example, compliance with Sarbanes-Oxley requirements or fixing a defect in a mission-critical server.

Release coordinators specify the business justification of the release to initiate the implementation of the release and to decide on corrective actions (if needed). If there is not enough funding to implement the release, you should create a contingency plan in case an adjusted business case for the release can still get the necessary approvals. If you cannot get your business case approved, you must inform the requesters of the release that the business case for the release has been rejected.

  1. Open the release request.
  2. Enter information in the Business Justification field on the Release form.

  3. Select a Business Justification to indicate the business reason for implementing the release request.
    Business justification information is important when the request goes through the approval process. Use this information to make sure that the necessary funding is available to implement the release.

  4. Click the Categorization tab and complete the appropriate fields to categorize the release request.
    The application automatically assigns the release request to the submitter if they have the functional role of a release coordinator when the request is saved. Assignments are determined by the rules configured by the application administrator.

  5. To create or relate other items to the release request, click the Relationships tab.
    You can create and relate release requests to your current release request before it is saved. You can also create and relate configuration items, change requests, and so on, to the release request.


    If you close the new release without saving, the new items are not saved. There is no relationship between these new items and the release request because the release request was not created.

  6. Click Save.
    Depending on the settings configured by your application administrator, you might see the Release form in Modify mode. You might also have to open the Release form in Search mode and query for your request.

To select release templates

The Release Template function allows you to select any templates that can be made available for your support group. Use the release templates to quickly and efficiently create standard releases with a minimum of mouse clicks and keyboard entry. Release templates are useful in any release request that follows well-defined methods for specific and repeated requirements, for example, Installs, Moves, and Add changes.

Before you begin

You cannot create, modify, or delete release templates in the Release Management application; you can only view them. You must use the Application Administration Console to create, modify, or delete release templates instead.

Any member of your support group with Release Master, Release Config, or Release User with Support Group Admin permissions can modify release templates for that group. For more information, see Configuring release templates Open link .

To apply the contents of the template to the release request

  1. Create or open a release request.
  2. Attach a release template to the request. The release template can be applied in the Draft state; that is, while the release request is being created.

    1. Click the magnifying glass icon next to the Template field on the release form.
    2. Select the support group from the Viewing Templates for Support Group.
    3. Select the correct template from the displayed list.

  3. On the Release Template Selection dialog box, click View to examine the contents of the release template.
    The template appears in read-only mode. Viewing a template lets you view its relationship, its task and task group templates, and other important features.

  4. Select a template and click OK.
    • The contents of the template are applied to the release request. The release template overwrites any field values that are already present in the release request, including any relationships or manifest included with the release request.
    • The value of the Notes field from the template is appended to the existing value.
    • NULL values in the template will overwrite existing values, except for the following fields:
      • Summary
      • Release manager
      • Support Company
      • Support Group Name
      • Support Organization
      • Business Justification
      • Categorization Tier 1
      • Location Company
      • Deployment Type
      • Risk Level
      • ServiceCI
      • Urgency
      • Change Environment
      • Lead Time
      • Change Reason
      • Impact
      • Product Cat Tier1
      • Release Type
      • Urgency

The contents of the template are applied to the release request. 

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