Page tree
Skip to end of metadata
Go to start of metadata

Various documents are created during the change process. Some information is recorded when the request for change (RFC) is initiated, and other information is collected or updated as the RFC progresses through its lifecycle. 

RFC and supporting documentation

An RFC must completely describe the purpose and urgency of the Change, its impact on the organization, and a backout plan in case of failure. The required level of detail depends on the size and impact of the Change.


RFCs are submitted through the support portal using the Request a Change offering. This form contains all the information needed to effectively plan, manage, track, and fulfill an RFC. If you are using Support Central to request a change, the following information is required:

  1. Change summary — provide a short summary of the Change you are requesting.
  2. Environment — provide the environment (development/tailoring, QA or production) where the Change is to be implemented.
  3. Notification contact(s) emails — provide the email addresses for any others who require notifications during the Change implementation.
  4. Emergency contact(s) — supply the name and email address for the contact person in case there is an emergency during the Change implementation.
  5. Requested change window — provide the date, time and time zone for the time slot when you would like the change to commence. BMC SaaS Operations will confirm that this slot is available to suggest an alternative.
  6. Change duration — provide the estimated time to execute the change.
  7. Risk level — provide the change's risk level from High (all business users are impacted during business hours), Medium (a limited number of business users are impacted), or Low (there is no business user impact).
  8. Detail change steps — enter the step-by-step instructions for implementing the Change. For each step, identify whether BMC or the customer is responsible for implementing the step.
  9. Back-out plan steps — provide a detailed list of steps for backing out the Change in case it becomes necessary.
  10. Post Change validation steps — provide a detailed list of steps for validating the Change after implementation.

The RFC should contain sufficient information to enable the Change Manager to assess the change at all review stages for approval or rejection. For example, the RFC tracks approvals before each of the following phases:

  • Moving the change from the development/tailoring environment into the QA environment
  • Moving the change from the QA environment into the production environment

Supporting documentation, such as test plans, implementation plans, and remediation plans, might be required. The Change Submitter should also specify whether each plan is included in the RFC. These plans must describe the Change before it is implemented. Smaller-scale Changes typically require less-detailed plans. Any required documents should be attached to the RFC request.

Additional documentation might be required. For example:

  • The RFC for promotion of a Change into the production environment requires customer approval of the Change and acknowledgement that the Change has been tested and validated in the QA environment. 
  • If the change involves a nonstandard customization approved by the Customization Review Board (CRB), the customization approval provided by the CRB must be attached to the RFC request prior to submission. For more information, see BMC Helix Customization policy and BMC Helix Remedy Customization Review Request process.

This information is also used by the Change Manager to assess the change for approval or rejection at all review stages.

For information about submitting the RFC, see Change request process.

Change calendar

If you use the support portal, your scheduled changes may be viewed from the  Change Calendar link.