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.

Creating a release request at the initiate milestone - Classic view

The section describes how to create a release request at the Initiate stage when using the Classic view of Release Management.

To create a release request at the Initiate milestone

  1. Review the RFCs to make sure you understand their requirements.
    This is a manual step you should perform before you open Release Management. You should understand the scheduled start and end dates, the CIs involved, the manifests necessary to complete the release, the CAB approvers, and so on.


    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.
    The Release form appears with the Request ID field automatically filled with an ID number for the release request. The release request initially appears in Draft status. To enable the release request from Draft status to be moved to its next status, enter information into the required fields.
  3. (Optional)Use a release template to fill out the contents 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 with the release request. For more information, see Selecting release templates.

    The Requested By fields are auto-populated with the details of the user who creates the release. If this user is not associated to a support group, the Support Company is set to the Location Company of the user. If this user is associated to a support group, the Support Company, Support Organization, and Support Group is set to the user's default Support Group.
    You can modify the Requested By fields if required. The Support Company list is modified based on profile of the user selected in the Requested By field. For users who are support staff the list includes only Support Group companies only for that user and for non-support staff the list includes all valid companies listed under Location Company.

  4. In the Summary field, enter a brief description of the release.
  5. In the Notes field, enter a more complete description of the release.
  6. From the Service field, select a business service CI.
    Selecting a business service CI automatically performs the following actions:
    • Populates the Product Categorization of the release request based on the categorization of the business service CI. You can modify the Product Categorization values later.
    • Relates the business service CI to the release request as a Related to association type when the release is submitted. After it is established, you cannot remove the association created between the release request and the business service CI from the Relationships tab. However, you can select another service from the Service field when the release request is in Modify mode.
  7. Select the Deployment type for the release request.
    You can use this field to further categorize the releases that are released into the IT infrastructure.

    Deployment type



    Stage the deployment of the release to a part of the user base. The operation is repeated for subsequent parts of the user base through a scheduled rollout plan, for example, the release coordinator identifies a set of changes that must be done at the same time, for example, all changes for Building 1 at Phase 1, all changes for Building 2 at Phase 2, and so on.

    You typically use phased deployments when new services are introduced into a store environment in manageable phases (such as retail organizations).


    All changes or activities deployed all at the same time in one operation with no restrictions, for example, a company-wide rollout of new servers.

    You typically use non-phased deployments when introducing an application change, and consistency of service across the organization is important.

    Note: ITIL Service Transition Version 3 describes non-phased deployment as the Big Bang method.

    Do not manually set the Milestone, Status, and Status Reason fields in the Release form.
    When you use the Process Flow Status bar 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.

  8. Select the Release Type for the release request.
    You use this field to further categorize the releases that are released into the IT infrastructure.

    Release type



    All components of the release are built, tested and deployed together. You typically 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.


    Includes only incremental changes and only those components or CIs that need to be included in this release. You typically use the Delta release type if your application was moving from version 1.0.00 to 1.1.00.


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


    Method to identify and review multiple changes, incidents, and problems that are candidates to target to implement in a release. The Backlog release type is a grouping mechanism that the CAB uses as their candidates to review for future releases.

  9. Select Impact to reflect 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 agreed service levels. Impact can be measured by the number of people affected, the criticality of the system affected, and the loss of revenue as a result of the service degradation or disruption.
  10. Select the Urgency to indicate the importance the requester assigns to the release request.
    Urgency 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 of the Urgency field is 4-Low.
    The following factors can be used 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
    • The type of service being disrupted, usually based on the CI involved
    • Awareness of the future impact on the business
  11. (Optional) To override the priority, select a new Priority to identify the importance you (as support staff) assign to the release request.
    Priority indicates the relative order in which releases should be addressed, for example, Medium. The priority of the request is automatically calculated for you, based on the Urgency and the Impact values that you specify. These values are configured in the Release Prioritization form. But you can override the calculation by selecting a different value, for example, High or Critical.

  12. Select the Risk Level to indicate the relative risk associated with the release, from 5 (highest risk) to 1 (lowest risk).
    The default value is Risk Level 1. The Risk Level is used as a criterion to determine required approvals.
  13. Click Rollup to accumulate the risk level from the related change requests (displayed on the Manifest tab).
    The highest Risk Level of all the related change requests is used when rolling up the Risk Level. The risk rollup is not performed automatically. You can override the risk rollup with a different value.
  14. Modify information as needed in the required fields on the General tab, for example, Company, First Name, and Last Name.
    This information is auto-filled, based on your logon. The Company is the organization or group that the release request is assigned to.


    If you type a letter or name into any of the fields with a (+) sign and press Enter, the field is autofilled. If multiple choices exist, a selection list or dialog box appears, to help you enter a name. Otherwise, you are prompted if no such letter or person exists in the system.

  15. (Optional) Modify information in the required Release Location Company field.
    The Release Location Company field is especially important in a multitenancy environment. In this field, you can specify the company, department, or other group that controls access to the release request.
  16. Click the Assignment tab and ensure that the release is properly assigned. You can manually reassign it to another release coordinator.
    1. Select an assignment method (for example, Auto Assign), and then click Set.
    2. Review the Support Company, Support Organization, and Support Group Name (if this information is not already supplied).
    3. Select the release coordinator to whom to reassign the request.
      For more information, see Working with release request assignments.
  17. Click Save to create the release request.
    This is the minimum information needed to create the release. You should include additional information as it is available to you.
  18. (Optional) If you need to suspend work temporarily on the release request, use the Process Status Flow area to move the release request to Pending status. Select Enter Pending and an appropriate status reason (for example, Manager Intervention) from the Process Flow Status menu.

    When you are ready to continue work on the release request, select Resume from the Process Flow Status menu. The Status field is updated automatically during the Process Flow for other options. For more information, see Performing additional functions from the Process Flow Status bar.

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