It's helpful to realize that service alerts are tenant specific. Once an issues is known in Office 365 and an alert is released, it's scoped to all relevant and potentially impacted tenants. This gives you an authentic dashboard experience that you can follow when relaying information to your support teams and end-users. This also allows you to create an incident response plan appropriate to your organization's business needs and complexity as we as one that's properly suited to your existing service desk incident response process. 

For the purpose of this exercise, let's consider three different incident support scenarios of varying degrees of impact. The first scenario would be one where you know that you have users were impacted and Microsoft has published a corresponding incident in the dashboard. Your workflow would likely be to give your service desk a talk track, potentially stand up an automated voice response to deflect help desk calls as well as to notify senior management. 

Depending on the incident and whether or not there's a workaround, you'd use this information to provide your service desk with the response that will allow them to address the tickets coming in by impacted users or at least a method to determine if the calls that are coming in are related to the existing issue being reported in the Service Health Dashboard. The second scenario is one where your service desk is receiving calls and support tickets or potentially seeing alerts from tools monitoring service health. We'll talk more about that a bit later. 

While Microsoft hasn't posted anything in the portal yet, in this case, it might be that Microsoft simply hasn't reported on the issue yet or it might be a client's had issue or it could be a problem with your internet service provider In this scenario, you would likely stand up an incident bridge on your side to begin troubleshooting the scope and the root cause of the issue. At this point, you'd likely give your service desk a heads up and engage senior management. You would also want to pull in Microsoft support once your triage process has determined that a support ticket is your next step. The resolution to this scenario is either going to be troubleshooting through to a solution for your issues or Microsoft posting an alert in the portal with either timeline of a fix or a workaround. 

At this point, your scenario goes back to the first scenario we mentioned. If you haven't arrived at a fixed tree of troubleshooting and support tickets, you'd provide your service desk with a talk track, automated response et cetera. Of course that the issue has been resolved or a workaround provided, the now would be your go to response to incoming tickets, resolve the issue for your users. The important key here is that your service desk has the tools they need to either resolve the incoming issues or is prepared to communicate to end-users while the problem is being further investigated or a fix is being worked on. Scenario three is where Microsoft had posted an issue that has major impact like this incident alert for Teams but no users have started calling in or reporting the issue yet. 

In this incident, your response might be to alert your service desk team as well as having your higher tier engineers on standby to respond when tickets come in. Your workflow at this point would be to again, give your service desk communication they can pass on to the end-user, ask your service desk to be on high alert and to page the appropriate team if they start receiving calls about the issue and also email senior management to give them advanced notice of a potentially high impact incident that may soon start to affect your business. Again you're going to want to be looking at your incident response from a severity and impact perspective. 

Looking again at this team's issue, you can see into the more detail section that impacted users can still access Teams on a mobile device while Microsoft continues to investigate and diagnose the issue. Now this becomes a different conversation for you and your service team. What are your current use cases for Teams and will your users be able to work well enough in Teams on their mobile devices until the issue has been resolved? Have you deployed Teams to your mobile users already or will you need to push out the application to your managed mobile devices? Are you using Intune to manage the application deployment or do you need to advise your users to download and install Teams themselves? Does your security stance allow users to use their own personal devices or are your users restricted to corporate devices only for business functions? You can see from the questions above that the workaround provided by Microsoft might be an easy fix. Maybe mobile works for everyone and it's business as usual until service is restored. It also might be quite possible that the workaround doesn't fit within your business function or security protocols. 

In which case you can have to make some decisions and potentially some concessions to allow the business to function as they need to without compromising your security and service integrity. Regardless of your ultimate approach, the important key here is that you've been able to build out a logical framework of incident response based on the information that Microsoft has made available to you in the Service Health Dashboard. And this information has empowered your service desk to be more responsive and hopefully to provide a better end-user experience.