Child pages
  • Azure AD Change Management Process

Versions Compared


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


CustomerRequestorSubmit a request for AAD change with sufficient information about business need. 
MI Support Coordinator 

Support the requestor through this process, at times suggesting or supplying technical detail and specifics the customer won't be able to supply. 

Guide requested change through the process to completion.

MI Engineering Solution Designer, Implementer 

As needed, design solutions which meet requests.

Implement approved changes.

MI Service Manager 

Approver (Gate #1), Approver (Gate #3)

Determine feasibility of requested change. Adjust change as needed. Determine what to do with change requests with significant issues. Set date of change.
Azure AD AAD CAB members (was Governance team) Approver (Gate #2) ConsultantsConsulted about requested change; provide input
AAD CAB managersApprover (Gate #4#2Approve or deny change via review for business use and risks. Suggests recommended changes to the requested change.


The MI Service manager is filled by the service manager or their designated alternate during leave.

The AAD CAB members are the members of the AAD Governance team is , which is defined separately at

The AAD Governance team has a leader role, which is also defined separately.The AAD CAB managers are comprised of:


The AAD CAB has a leader role, which is filled by the MI Service Owner.

CAB members and managers can select a temporary alternate should they be unavailable.

Change Request Process

 Standard  Comprehensive Change Request vs. Routine Change Request


Standard Comprehensive changes include the following:

  • Any request that meets the entry criteria and not previously called out explicitly as an routine change by the AAD CAB

Routine changes do not require the CAB to approve them. The 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)


  • the enterprise Azure AD tenant design, including the following items
    • namespace design or accepted domains,
    • tenant-wide configuration settings,
    • enable or disable a new Azure AD capability that Microsoft has released (depends on what the default state of the new capability is)
    • change to provisioning or authentication integration design 
  • Azure services which can only be enabled or changed by a tenant global admin (e.g. Azure RMS, InTune, and many more)
  • a one-time change or recurring change--outside existing service design--to some number of objects in our AAD
  • implement significant management or operational practices (e.g. AAD app approval process or tenant global admin practices)
  • a change to MSCA service design which may have impact to the Azure AD design (note: MSCA may have a separate change approval process, but when a change intersects with AAD design should that change should also use this mechanism)

Process Steps