Skip to content Skip to site navigation

Change : Tips, Tricks and FAQs

Tips & Tricks

The Change Request "Assigned to" is the Owner of the Change  and is the person in control of the change process.  This person defines what needs to be done, when it needs to be done, who is going to do, and confirms the results and closes the Change upon completion.  They are also the person who should insure that the change is fully approved by the Scheduled start of the change.  They either represent the change at the CAB meeting on Wednesday if the Risk/Impact is either 1-Very High or 2-High or they designate a person to represent the change.

Describe the change request fully during the creation process.  This includes insuring that all servers and/or affected and impacted Service Offerings are noted in the change request.   The "Impact Risk Analysis" field on the planning tab should not if there planned impacts to services or if something goes wrong during implementation.  

The Short Description field is the most visible since the CAB using this on the agenda page and in the minutes.  Be descriptive in the Short description field and include Service being impacted.  Instead of saying "Apply Monthly Security Patches", consider saying "Apply Monthly Security Patches on JIRA and Confluence related servers."

Frequently Asked Questions

What types of Changes need to be recorded in ServiceNow?

Is there a type of Change request which doesn't need to go through the approval process?

  • Standard Change requests do no need individual approvals.  The Standard Change Template is approved once at CAB with the expectation that no future approvals will be sought.

Can I copy a prior Change Request?

  • Yes, all "Normal" change requests can be copied.  You can then edit the information that needs to be changed and request approval.
    • Use caution when copying change requests originally created by the JIRA interface.

Can I use a template to create a new change request?

  • Yes, you can use any Change request regardless of state and make it one of your personal templates.  See 
  • Yes, or you can submit a request for a Standard Change request template which doesn't need to be approved after the initial approval. See KB00010743

Are there suggested standards around the fields in Change Requests?

  • Here are some useful guide lines:
    • The Change Request “Assigned to” is the Owner of the change.  This is the person that can make changes to change before requesting approval.  They sheppard the through the approval process.  They can withdraw & close the changes.   Basically if you’re the “Assigned to” on the change the only thing you can do if you’re in the “Assignment group” is make yourself the owner by changing the “Assigned to” to yourself, then you can act on it.
    • The first step in the approval process is for the Assessor.  The assessor can make changes to the change requests and tasks, but only when working as the assessor.  In many cases the person acting as the Assessor will also act as the Business Approver, but once out of Assessment, no body but the UIT Change Management group can modify a changes request or associated tasks.
    • Both the Assessor and Business Approver should make sure to Delegate authority before leaving on vacation or when sick. That way others can approve on their behalf.  If this is not done, contact the UIT Change Management group.  In some cases it may expedite approvals if the Group Manager delegates approval to a trusted lead or other manager to approve in their absence.
    • If the change affects either of the Hospitals, be sure to include the appropriate org in the Impacted Orgs field as needed (e.g. SHC or SCH).
    • Please review the requirements of Change Lead Times
    • On the Planning tab, the Change plan should include all the work associated with the change or refer to an external doc or Change Tasks for plan.  
    • On the Planning tab, the “Risk and impact analysis” is an analysis in story form, not one or two words.  This should clearing describe impact and possible impact to users during and after the changes and in some cases the impact if the change goes wrong. 
    • On the Schedule tab besides Planned Start and Planned End, users can also create an outage that will go on the Alerts page.  To do so, users should the Change Request first, then all they have to do is double click in and enter dates in the Begin and End field and save the change, the rest of the fields will be populated automatically.  If they need to add details to the Outage or send communications, they should click on the “i” next to the Outage. If the Change Record was not saved before creating an outage, the outage will be created as unplanned (Outage) and should be changed to “Planned Outage”.
    • On the Risk Assessment tab, users should answer the questions honestly with both dimensions (during and after the change) and keeping in mind change that goes smoothly or  have issues during implementation.  Use the highest answer appropriate.
    • If you are the Change owner (Assigned to) on the change and another group is doing the work, place the work the other group needs to do in a Change Task and assign the task to their group.  This prevents the need to give ownership of the Change Request to the other group.
    • For patching or other types of changes, the recommendation for the Short Description is along the lines of “Apply OS patches for <period> to servers supporting <listing of the services supported by the server>.  With the rest of the information in the Description field including the servers being patched.
    • Include additional (ad-hoc) approvers in the Approvers tab in the Related Link section
    • Include additional Affected or Impacted CIs in the Related Links section
  • Patching Related Change Requests which reoccur:
    • Ownership (initiation of Change)
      • The group/person responsible for insuring that work is completed.  In the case of OS Patching, that’s the sysadmin teams. For DB patching that’s the Infrastructure team responsible for the database.
    • Affected CI
      • This is the “Service Offering” (aka CI = Configuration Item) that’s being changed.  In the case of the OS Patch it will be the System admin’s Service Offering.
      • The controls an approval.
    • Short Description
      • Should be Type of Work, Period, Services (if they all don’t fit, add to Description)
      • Example OS Quarterly Pathing  Feb-March 2017  Oracle Financials
    • Impacted CI
      • Use the Generic Infrastructure Service Offering (CI) for the group who’s applications are running on the servers.
    • Approvers
      • One approver will be for Affected CI (for OS )
      • One approver will be for Impacted CI (for application group)
    • Outages
      • One Planned outage per Change Request (right now this is a manual process) with all the services listed in either the Short Description, Message or Details field.
    • Risk and Impact analysis
      • More than one word.  The information should include what’s expected during change as well as after change and what happens if change goes bad.
    • Tasks
      • Change Requests will have a task for required DBA work on the patching change requests.
      • Task should be assigned to group and include “Expected start date”

Do you have examples of well formed Change Requests?

  • Yes, see:
    • CHG00006207 (system upgrade: good everything)
    • CHG00006231 (simple network change, good content)
    • CHG00006179 (PSU patch w-Implementation Task)
    • CHG00006141 (JIRA code migration w-Implementation Task)
    • CHG00003983 (OS patching, good content w-Outage)

Why did an "Outage" (unplanned) get posted for my Change Request which was planned work?

  • Agreement at CAB stipulated that any Change Request which causes an outage with no "Planned Outage" created against the change will be for ITOC to place an "Outage" for the incoming incident (which would be linked to the change) until the Incident/outage is closed.
  • If your Risk and impact assessment thinks there a chance of an impact to users, Change Owner (Assigned to) should place an Planned Outage for the Change Request.

Does my Change need additional communication?

  • The respective Business Owner and Service Owner are responsible for managing the relationship with clients using their service, and they make the final decision regarding the need for client communications. The UIT Communications team is available to assist with any communications planning and implementation as needed. You can reach the team by submitting a help request at uitcomm.stanford.edu.
  • See the "Planned Service Maintenance Communication" document to help with answer your questions.
  • Plan on contacting the the UIT Communications as soon as you know you might need help.  Plan on at least 2 weeks lead time to get communication out (more time desirable), but they can expedite on a case by case need.

I have a: sensitive, security related, very technical change; what information should or shouldn't be included on a Change Request?

Changes should be well documented including all the work required to be successful, however, credentials or other types of High Risk data (per ISO) should not be included directly in the change but linked or noted where to retrieve information. 

"Change plan" can include: specific patch number, server names, ports, other system configurations, specific steps, etc.  For example, "Step 2: Install certificate located in Subversion at link ..."

"Description" can be generalized, for example instead of saying “This change will fix the issue that allows anybody to download any users performance evaluations in Simple Eval”, simply say “This change will fix an unintended disclosure vulnerability in Simple Eval”, while the "Change plan" field can still include "Apply PeopleSoft patch 12345".

Where do I find more information about changes?

Last modified January 8, 2024