Giva Blog
Stay in Touch with Giva's News & Updates

RFC Status Workflow-IT Change Management Software

RFC Status Workflow-Giva eChangeManager


Here is an ITIL compliant change management process diagram.


Status Change Flow Chart:


Click to see more at:  Status Change Flow Chart

Various stages in the change life cycle

Status = NEW

A User creates the RFC in eCM. When created, eCM automatically notifies the Change Manager. The Change Manager approves the change in concept or rejects it. If he approves it, status = PLANNING. The service group field is completed and eCM automatically notifies the service group via an email. If he rejects it, he makes status = REJECTED and completes the rejected reason fields. The Change Manager should also write a brief description of the rejected decision in the Change History field. When the Change Manager updates the record, eChangeManager automatically notifies the requester.


The implementer or service group develops the implementation, test and backout plans. He documents this information in the change record or in attached files. By the end of the PLANNING stage, the Service Group must complete the “Implementer,” the “Builder” and the “Tester” fields. When the planning is complete, the service group or implementer notifies the Change Manager as follows. They put a note in the Change Record History and they click the “Notify Change Manager” button. He will get an email with a copy of the note requesting his review. The Change Manager sets the status = PENDING and selects one of the Waiting Codes.

Status = PENDING

If the Waiting Code = “Awaiting Approval,” and the priority is ”URGENT,” then eChangeManager notifies the CAB and the EC. If the Waiting Code = “AWAITING APPROVAL,” and the priority is anything but ”URGENT,” then eChangeManager notifies the CAB. If the Change Manager selects any of the other codes, eChangeManager notifies the service group or the implementer if designated. Some other Waiting Codes might be “Implementation Plan Development,” “Test Plan Development,” or “Backout Plan Development.” When the Change Manager gives his approval, he changes the Status = APPROVED.


The Change Manager changes the status to APPROVED if: (1) receipt of all change documentation has occurred and (2) approval from the CAB and/or EC. The approval process usually includes a meeting to discuss changes. This is where any objections or modifications to the implementation process take place. The CAB and EC give their approval for the Change Manager to move forward with the change process. When all is in order, the implementer is designated, the scheduled date set, the status = SCHEDULED and eChangeManager notifies the implementer. Only the Change Manager and the Emergency Committee members have the ability to change the status of an RFC to “APPROVED” in the status menu. The status of “APPROVED” does not appear in the drop down menu with all other roles. Once either the Change Manager or an Emergency Committee member changes the status to “APPROVED”, it will then show up in the status menu of all other system users.


When the status = SCHEDULED, the change appears on the Forward Scheduled of Changes Report. This is the most critical of change reports for the helpdesk. It provides them with all scheduled changes and allows them to prepare their support accordingly. When the implementer is ready to implement the change he changes the status to status = WIP.

Status = WIP

When the status moves to this state, eChangeManager notifies the Requester and Customer. Upon completion of the change, the implementer updates all relative fields in the change record. He notifies the Change Manager that he is complete by clicking the “Notify Change Manager” and updating the record. After the Change Manager completes a post change review, he changes status to status = CLOSED.

Status = CLOSED

Status changed to “CLOSED” after: 1) Requester confirms change; 2) all documentation is entered into RFC, 3) negative impact of change noted in the Induced Problems field and 4) the Change Manager completes a post-change review. At this time, the Change Manager selects a “Closed Code: and updates the RFC.


Status changed to “REJECTED” can happen at any time. Notification automatically goes to the requester.