RFC Instructions and Field Description

Instructions and Field Description

This section describes all of the fields of the Information Technology Services Change Management Request For Change (RFC) form. Use it as a guide to complete the RFC form.

If a field name is red it is required for the Status and options selected.

Information on the Tabs/Sections:

RFC ### in UNL ITS Change Management
Field nameInput typeInformation to enternotes
Request Title text The brief title of the change, shows on reports and the select screen in the RFC workspace Required to save RFC
Severity of Event Select one A summery of the severity or urgency of this change. Normally left at medium. Can effect approval esclation.
Status  Select one The current state of the RFC in its life-cycle.
Status of  Draft The initial status of a change request. Many fields are not required in this status so you can work on gathering informaion and input from others.
Status of  Awaiting Change Manager Approval Place an RFC in ths status to begin the approval process. The system escalates this RFC to the managers of the Assignees for aproval. (People's managers are from a lookup table in the RFC workspace and updates should be requested via ticket of either the footprints team or Loren.) (Contact Loren if your manager is out and you need this step bypased.) Select this status to start the workflow
Status of  Awaiting CAB Approval Once the manager(s) approve in "Awaiting Change Manager Approval"  this is the next step. The CAB (Change Adversary Board) is the members of Directors+ and they review and approve your request.  This status is never selected, it is generated by workflow
Status of  Implementation The status once "approved". Approved changes waiting for the implimation date and changes in progress are in this status. This status is never selected, it is generated by workflow
Status of  Evaluate The Status you select when you have completed your change. RFCs in this state appear on the completed RFC report. Auto‑escalates to a status of closed after several days
Status of  Rejected
Status of  Canceled If after entry your RFC is not going to be implemented select this status.
Status of  Closed The Status of an RFC after the services affected have been evaluated for unintended outcomes due to the change. RFCs in this state appear on the completed RFC report for 7 days after the last edit.
Assignees none in this section Assignees appears in the "RFC ### in UNL ITS Change Management" section but is configured in the "Assignees and Notifications" section

Contact Information
Field nameInput typeInformation to enternotes
all - The person listed in this section should be the person who internal staff can contact about this change.  Supervisor voting is based on this field.
Last Name text Contact's last name (LDAP sn) Required to save RFC
First Name text Contact's first name (LDAP givenName) Required to save RFC
Email address  text Contact's email address (LDAP mail), if an address other than the directory listing is prefered then update this field after autofilling the rest of the fields. Required to save RFC
User ID text Contact's MyUNL username (LDAP UID), not nessessary but a usful field for doing autofill. 
Phone Number text Contact's phone number, if an phone other than the directory listing is prefered then update this field after autofilling the rest of the fields. Please use the person's mobile or direct number if the contact has a front desk number in the directory. Required to save RFC
Pressing enter with your cursor in any field in ths section executes a search and autofill from directory information (LDAP).
Only one partial field is required for a lookup, if there is only one match it autofills the fields, if more than one macth it gives a selection list. The default search is a starts with search (search is and if data in more than one field), if you want to do a more advanced search use the Select Requestor button.
General Information
Field nameInput typeInformation to enternotes
Request Type Select one Normal and Emergency are the to defined types of changes in policy.  
See the approval work flow PDF.
Changes which fields are displayed and which are required
Request Classification of Emergency An emergency change in ITIL. A change that falls out side the policy of a normal change, generally caused by an unexpected outage or an urgent security update.
Request Classification of Normal A normal change in ITIL. 
Campus Impacted Multi
Organization of UNL,UNO,UNK, Central Administration, State Colleges Select all that apply, enterpise services like Firefly/Sap, PeopleSoft and EMS should select all
Organization of Other Select if this change effects services like extention offices, ESUs or off campus research sites.
Change Codes Multi
Change code of Security
Change code of Preventive Maintenance
Change code of DR Mitigation
Change code of Enhancemant
Change code of Break Fix
Change code of Third Sunday Maintenance Select for this change to appear on the Third Sunday Report. All ITS‑ES changes occurring during the Third Sunday maintenance window need this status.
Change code of Vendor Maintenance
Change code of Network Nebraska
Change code of ES Outsite Window Select for this change to appear on the ES Outsite Window Report.
Closure Code Select one Only appears in Evaluate and Closed statuses
Closure Code of Compleated as planned
Closure Code of Compleated with issues
Closure Code of Unsuccessful
Closure Code of Rescheduled
Closure Code of Canceled
Application(s)/​System(s) to Change text

The system or process to be changed. Please include services effected.


Description of Change


Detailed description of the change request.

Target Implementation Date

Date and time select

Date and time when the change is starting to be implemented.


Estimated Completion Date

Date and time select Date and time when the change is expected to be compleated.

Reason For Change


Define as precisely as possible, the justification for the change.  Indicate why the change is needed, including critical dependencies such as a new statutory requirement. 
Describe any risks or inefficiencies that the University will be incurring if the change is not implemented (e.g. missed deadlines, legal penalties, delays, anticipated failures).

Business Units or Processes affected by the change

text Describe the business units, business processes, and process owners affected by the change.

Resources required for implementing the change


Describe any dependencies for the operational implementation of this change or business solution (e.g. people, skills, roles, tools, systems, processes, organization, and technology).

Communication Method


Communication Method of

IS Alert

Communication Method of

ITS Newsletter

Communication Method of

Service Team

Communication Method of

Tac Team presentation
Communication Method of Targeted users list
Communication Method of Tech Info
Communication Method of UNL Today

Implementation plan


This should invariably require that an attachment of a checklist, project plan or a link to the implementation plan depending on the change be included here. Otherwise, describe the steps that will be used to complete the change.



Explain the testing method, environment and status of any ongoing testing for this change.

Risk Assessment


Describe the risks that could affect the implementation of the change, indicating its probability of occurrence, the impact, and the action to be taking if facing the risk. Does the change jeopardize security, backups or require the modification of the business continuity and contingency plans? If so, describe here specific changes that need to be reflected on documentation and testing procedures to maintain security, ensure the integrity of backups and keep the continuity and contingency plans accurate.

Rollback/​Back out plan


An exit strategy must exist to reduce risk to the production environment in case the change doesn’t work. Describe your trigger for rolling back your changes. Provide the link to the location of your plan or attach your checklist/back-out plan. Some changes do not have a viable rollback, when this is the case please indicate why rollback will not be an option.

Other Comments/​Special Considerations


This section offers some flexibility in adding any comments.

Field nameInput typeInformation to enternotes
Description* diary text This is the system field where you (the approving manager and the implementation team) enter notes about your progress (before, during and after the change). As a diary field the contents of this field are time and date stamped each time you save. Required to save RFC

Assignees and Notifications
Field nameInput typeInformation to enternotes
Assignees member select Please select the people directly working on this change. If your change requires a DNS change at implementation time please coordinate with the DNS team and add a member of that team. While there are teams listed under workspace members please do not select them. They are used for automated workflow only!

Send Email To

check boxes By default the system only sends emails at 2 points; to approvers when an approval is requested and to assignees when approvals have been meet. 
If you want someone to get notified when you save your RFC please check the appropriate box. (the requester box refers to the person in the contact section)

old instructions: