Child pages
  • Azure AD Change Management Process

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



Standard changes include the following:

  • Any request not previously called out explicitly as an expedited routine change by the AAD CAB

Routine changes do not require the CAB to approve them. The accepted approved routine changes include the following:

  • If a new setting or Microsoft app is deployed to our AAD tenant as enabled, upon discovery a tenant admin can immediately disable that setting/app treating it as a routine change. Communication of this change should happen among tenant admins, and to the MI service manager. Back out: Remove as routine. Goal: Mitigate Microsoft from implementing changes without our consideration. (approved 2/8/2016) 
  • Requests for Basic AAD Applications authored by UW developer. Back out: Remove as routine. Goal: Streamline AAD applications for UW developers, removing friction of waiting a month for low-risk use; value is provided in a timely manner. (approved 4/11/2016)

Entry Criteria

The MI service has a request for a change to:


  1. Customer submits a change request to MI Support via UW Connect.
  2. MI Support reviews the customer's request for enough information that it can be acted on.
    1. Open CHG record, if needed. This may require having both a REQ and a CHG record, with the REQ to communicate with the customer.
    2. If necessary clarify with the customer to determine any unclear information. If needed, engage MI Engineering to design a solution to the customer's request.
    3. If needed, MI Engineering reviews request and designs a solution.
    4. MI Support has a documented request for change that must include:
      1. Specific details about what is to be changed
      2. What the back out plan is, should the change not go according to plan
      3. Some explanation of the desired outcome/goal behind the change–what's the business need this requested change meets?
      4. A desired timeframe for the change. NOTE: specific dates are not required at this time.
    5. MI Support assigns the request to the MI Service Manager for review for feasibility.
  3. Gate #1: MI Service Manager determines the feasibility of the the change request and considers the relative prioritization of the change, i.e. whether it needs speedier consideration or might be an emergency change. 
    1. If the change request is a routine change, then the MI Service Manager assigns the request to MI Engineering for implementation. Go to step #8.
    2. If not approved, the MI Service Manager will determine how best to handle/address. This may mean going back to 2a, 2b, or denying the request.
    3. If feasible, then
      1. MI Service Manager assigns a specific date for the change that reflects the relative prioritization compared to the overall service backlog and available resources and attempts to honor the customer requested desired timeframe
      2. MI Service Manager marks the change as feasible. 
      3. This results in a notification to Azure AD CAB members for comment and ultimately an approval decision by CAB managers. Unless otherwise noted, the approval will happen at the monthly CAB meeting. If speedier approval is needed, an ad hoc meeting will be scheduled.
  4. Gate #2: AAD CAB reviews change request.
    1. AAD CAB members discuss change, implications, and suggest recommended changes to the requested change. They supply these via UW Connect or by responding to the email notification.
      1. AAD CAB reviews request to ensure that business uses are enabled and risks are mitigated.
      2. Questions about potential issues are directed to the MI Service Manager for clarification/resolution.
      3. All discussion and concerns are expected to be voiced in advance of the monthly AAD CAB meeting.
    2. The monthly AAD CAB meeting provides a venue for the AAD CAB managers collectively review pending change requests and make a final decision to approve or reject those changes.
    3. When an AAD change is approved, an AAD CAB manager marks it as such within UW Connect. This signals the MI Service Manager to proceed.
    4. If not approved, the request has significant issues and needs further work. The request is assigned back to the MI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, or denying the change request.
  5. Change implementation
    1. MI Service Manager assigns approved change request to MI Engineering for implementation 
    2. For changes which are potentially customer impacting, MI Service Manager announces planned change via MI-announce mailing list, to the customer via the original REQ request, and where appropriate other mechanisms.
    3. MI Engineering implements change and updates CHG record listing results of change. Separately MI Engineering updates service design documentation
    4. If the change doesn't go well, MI Engineering executes the documented back-out plan. The UW Connect CHG record is then re-assigned to the MI Service Manager to determine how best to handle/address. This may mean going back to 2a, 2b, 4a, 6a or denying the request.
  6. Change resolution
    1. MI Service Manager reviews CHG record results and closes it.
  7. Change request resolution 
    1. MI Support resolves original REQ request, if needed.

Change Practices

  • The AAD CAB will meet monthly as part of the AAD governance team meeting. If there is no change to approve, they need not attend.
  • AAD CAB members attend the AAD governance meeting not as voting members of the AAD governance team, but can provide input and direction
  • AAD Changes should be submitted at least 1 week in advance of the AAD governance meeting so AAD CAB members have time to review and ask questions ahead of time.
  • AAD routine changes are documented. New types of routine changes are approved as an AAD change.