Process Automation & Insights Across M365 Data Using Microsoft Graph & Azure by Ayça Baş

As we did the introduction already

I'm going to talk about process automation and insights across M365 data using Microsoft Graph in Azure today

Just to recap, my name is Aisha Bash and I live in Dubai

I'm working at Microsoft Developer Relations as a Cloud Advocate. I'm focusing on Microsoft Graph and Microsoft Teams specifically

I'm a developer and I'm trying to create projects around Microsoft Graph by using Azure

I'm posting a lot of stuff on Twitter in my own blog and also Microsoft official blogs too

If you are interested in learning more about it or if you have some other questions, you can always reach out to me on Twitter

Let's start with the agenda today. First of all, I'm going to talk about a little bit of overview of Microsoft Graph, and then we will jump into Microsoft Graph and Azure App Development

Actually, my speech is going to be pretty much 100% technical. After that, we will discover user interactive scenarios

Then we will check what we can do with non-interactive scenarios. And the last part we're going to cover is reporting, ytics, and insight scenarios

And at the end, I'm going to cover some links that might be useful for everyone

Okay, so let's quickly have an overview around M365 platform. As you know, M365 is quite big, and we have lots of documentation tools and lots of products we can consume

But today, specifically, we're going to discover what we can do with the data inside of those products

Let's think about, for example, Microsoft Teams or Outlook. We're using all of them day to day, and we have huge data in the background

Every company or individual has huge data in the background of Enter 65 platform

and actually by using them, we can create great bot projects, web apps, or demon apps, workflow automation

or we can also use these data in the ytics for auditing purposes or some business review perspective and so on

And to be able to reach out that data, we always use Microsoft Graph

Let's check out what is Microsoft Graph. it's a gateway to your data in the Microsoft Cloud

Let's say that we are using, again, day-to-day our tools like calendar tasks

We are joining groups. We are chatting on teams. And each time we use these products, your data is staying under Microsoft Cloud

That doesn't mean that Microsoft has access to your data. You actually have access to your own data

and by consuming all this data, you can create great projects around it

Like by consuming all these calendar, mail, tasks, information, for example, you can create a great agent assistant for you, bot assistant

which can gather all of the important events of the day, or you can just automate background provisioning processes by using Azure functions

and we are going to discover all these scenarios in this presentation

So quickly to be able to build an app by using Graph and Azure, first of all, you can check out docs. You can go to aka.ms slash m-graph, which you will find lots of documentation around each Graph-related product and how to consume that

Plus you can see there are lots of tutorials and quick starts documentation around languages you prefer

If you are a .NET developer, you can choose .NET and go through the entire tutorial

You can build an application from scratch. If you prefer Angular or React, you can choose React and you can again create an application by consuming Microsoft Graph from scratch

The second tool I highly recommend is Graph Explorer. It's a free tool that we can go ahead and sign in

When we sign in, we can start consuming our own data, and we can call any graph API we want directly

through the Graph Explorer. I'm going to show that in one of my demos today

And the third thing, we need to create an application in Identity Platform

We need to register an app in Azure Active Directory. By using that app, you're going to access to M365 data

Let's say you want to reach out to email data, then again, we need to create an application in the background

say that we need permissions for the email or calendar, and whenever user consents the permissions

or whenever admin consents, we will be able to reach out that data and continue our process

After configuring the app permissions, we need MSAL Microsoft Authentication Library for signing

in and getting the token, once we have the token of the person or of the app, then we

can call Graph API wherever we want, literally. It can be a mobile app

It can be functions, jobs running in the background. It can be web application or any kind of app

It's basically an API, REST API, you can call wherever you want. So this is a quick overview of Graph Explorer

Graph Explorer, as I mentioned, it's a tool I can actually quickly show you

It's a tool where we can authenticate quickly. After signing in and giving the consent to Graph Explorer

we can choose any API we want to try out on the left side

And we can see our data in the response preview. In addition to that, in the code snippets

you can find out how to implement data in your applications. If you are using C Sharp, you can copy paste

your C Sharp part in your application, and it's going to work

So I want to quickly go through the documentation with you as well as the Graph Explorer

because I'm assuming it's going to be the first time for some colleagues to see these kind of tools

So I opened the browser. I can zoom in a little bit

I did that again. I did it in the morning too. Zoom, okay

So first I'm gonna go to aka.ms slash m-graph. With that, I'll be directed to documentation

and in this documentation, you can find all of the REST API guidelines

API version one and beta is available. And if you're new to Microsoft Graph

you can check out quick starts and as well as the tutorials. Quick starts are the part

where you can pick the language you prefer. Let's say that I want to do the Angular web

application and it just showing you the prerequisites what you need to install And if you want to end to end walkthrough you can just click here and it going to direct you to documentation And it just three minutes quick start If you interested to have an application scenario running end and you

want to build something from scratch, then you can go to tutorials, choose the language you prefer

let's say I want to build something with SV.NET Core, then this is the entire documentation

You start with introduction. When you follow all the steps, at the end, you have an application

with Microsoft Graph up and running. Congrats, you built your first app by using the official

tutorial. This documentation, I find it quite useful. That's why I wanted to share

Another thing I want to quickly go through is a Graph Explorer

If you go to aka.ms slash g-explorer, you will be directed to Microsoft Graph Explorer

This is a free tool in open source as well. What I can do is I can quickly sign in

And my pull-up is here. I'm just going to choose the account I want to sign in

I'm choosing my demo account. Oops. Let's choose another demo account. And after that, you can see my profile here

Then if I want to get my profile, I just run the query from here by using related requests

I want to have a get. As you see, I have a response overview

you can see my display name, job description, email address, and so on. So you can run any

thing, any API you want. There are actually more than 5,000 API in the background of Microsoft Graph

So capability is huge. What we can do is really quite big. So you can just explore lots of things

from here. For example, I want to get all my calendar events. I just click here. It changed

the end point from here and it gets whatever I have in my calendar here. If you want to

implement this in your application, if you're using C-sharp, you can just grab this code

and paste it here. Same for JavaScript, Java, and Objective-C. Okay, this is it. I'm going

continue with how we are going to build something by using this data. So, our big data is going to

be here M365 data. By using Microsoft Graph, we are able to get lots of data in the background of

M365. We can consume, again, calendar data, anything related to your organization in the

directory, as I mentioned, there are more than 5,000 different APIs in the background of graph

So capability is huge. Literally any data in the M365, you can reach out to your own data

And after the authentication by using Oath 2.0, the rest is choosing your development environment

There's no limitation. By using the development environment, you can use Notepad or you can use

Visual Studio, Visual Studio Code, and you can choose your own language

In Graph, you don't have any restrictions of building your app in any language

If you're a JavaScript developer, you can consume the API in your JavaScript application

If you're an iOS developer, you can consume, again, the same API in your iOS mobile application

and you can host your app wherever you want. Today, we're going to discover Azure solutions

with Microsoft Graph, and hopefully you like it. So key scenarios when we use Microsoft Graph

is basically two things. That's why I divided the entire session into tool pieces plus the reporting

The first one is user interactive. The second one is non-interactive. First one is when we create application

in Azure Active Directory, think that the application we're working on is going to be consumed by end user. Let's say it

can be a web application where user clicks and log in. After that, they can see their own data

like profile information or get their email information, so on and so forth. Or it can be a

chatbot where chatbot can gather all the calendar data to you whenever you ask. These kind of

scenarios, we always ask end user to consent the permission. So when we first start, then we give a pop-up saying

that this application wants to reach out to your calendar data. You need to give consent, and then we

will be able to reach out. This application will reach out to your data

Second scenario we use is the non-interactive scenario. In non-interactive scenarios, it's common to have background automations, process automations, like provisioning scenarios

Let's say whenever a new person is added, then create a subscription and add that person in the onboarding teams and so on

So in this case, we need consent from the administration. administration. In Active Directory, we're asking admin to give consent because in this case

these kind of scenarios, we don't engage with the end user. All of the provisioning is going to be

in the background without any touch of the end user. And we will only notify maybe administrators

saying that we changed this, this happened today and so on so forth. Let's start with the first

scenario. It's the user interactive scenarios and it's the one that as a developer we really like

building like chatbot scenarios, web applications. I really like consuming graph API in those kind

of scenarios. So basically what we do is once we build the application and register in Azure Active

directory and once user logs in click on login button then user consents to the permission

required by app let's say calendar permission after that app uses user access token to make

api calls that means we reach out to users um token by using msal and the end result is going to be

your app by using the permissions and the token is going to get the data we

required. Common scenarios for that is generally email any person we want

calendar scheduler bots where it asks you to for example this is your calendar and you type botlet do this do that and bot is following your comments and calling Graph API in the background

and doing whatever you are asking to do. So in Azure Active Directory, for interactive app registration, we use delegated type of permissions

That means that we always ask end user to give consent to us

In this case, it's showing like read user files, sign in and read user profile

That means that, let's say on the top, we have sign in with Microsoft button

When a user clicks on that button, then after giving the email address and password, we ask with our application created in Active Directory

we show the end user saying that this application needs to read your emails and view your profile

information. If you accept that, then application will be able to do API calls, Graph API calls on

behalf of you. Then with that, you will be able to return your calendar data or email data through

the bot. Let's say that we are using Lydia's access token. We ask Lydia to give consent to us

When she gives the consent to us, then we are going to return response 200. Okay. And we get

Lydia's emails and all the email data in her inbox. But that doesn't mean that when Lydia

gives us an access, we can use other people's token. We cannot because every person who is using that application

that bot, needs to give consents on behalf of themselves. So whenever Lydia gives consent, if we try to call same application

with someone else's token, even in the same organization, it's going to return 403, forbidden error

and we will just see that access is denied because we don't have the credentials and the token

So Peter needs to give permission on behalf of himself. Very common scenario is bot calls Microsoft Graph

to access calendar mail tasks. This scenario is actually asked from many enterprise level customers

as well as the developers. They like working with bots and I also, I'm a big fan of bot framework too

Actually, the new skills are published by the bot framework. They just release a calendar skill

email skill and to-do skill. That means that these skills are pre-built for you

and they're consuming Microsoft Graph already. You can literally just get the SDK

I just shared a link here, ak.ms slash bot-skills. Here you can get the SDKs, whichever skill you want, and you can run the code and test it for yourself

And you can publish it to Azure bot service and your app is going to be ready

So you can have your to-do bot, you can have your email or calendar bot

Same thing can be done all together as well. These components, these skills can be attached to bot framework assistance too

So there is a bot framework solution called virtual assistant, and you can actually attach this productivity components like email skill, to do skill, and calendar skill in your virtual assistant, and your virtual assistant will be able to do all of them

So I highly recommend you to go ahead and check that. Let's continue with non-interactive scenarios

So, non-interactive scenarios are generally the scenarios where administrators will be quite interested

So we don't have any user in the scenario. Everything is happening in the background

We ask admin consents for the app for the specific permissions. Let's say I'm running functions in the background

I am saving all attached files sent by emails in our entire organization to a database

In this case, I need to register an app in Azure Active Directory. Then admin needs to consent the permissions, and we need to define which permissions we require

like files read all, users read all, mail read, and so on

Once admin gives the consent, then app uses its own credentials to authenticate

We don't need any user's authentication or token anymore. So, at the end, app has full privilege as long as we define here, app will be able to

reach out to files, user read, and mail read. So, in these kind of scenarios, we don't have a visibility of user

We just send notifications maybe in the administrator level saying that subscription provisioning is done and so on

Let me give you an example about it. During the COVID situation, we had lots of customers talking about moving entire working or education or healthcare environment to teams

and because we didn't know that it's coming, they need to do this entire move in a couple of weeks

We were really limited in the time. So what happened is that maybe thousands of users

needed to register in Azure Active Directory. After that, we need to assign them in certain teams groups

so they can communicate with their nurses, doctors, or their students, teachers, and so on

These kind of scenarios cannot be done manually by an administrator because it's, again, thousands of people, thousands of work

We need some kind of flow in the background running on behalf of the organization

So, these non-interactive app scenarios are quite useful for this kind of background workflow automations

In this case, in Azure Active Directory, once we create the application, application

permission level should be the permission type should be application. And at the end, our admin needs to consent this from Azure Active Directory

After that, our app will have full access of the data required

So let's take a look at that. calls API to access any mailbox. Since we give the permission to reach out any mailbox, it's given by

the admin, then our app can call any user token and get the data we require. Let's say that we

would like to gather everyone sign log and we want to check if people working from home are working after work times or if they comfortable if they working too much after work stuff if you want to do some kind of ysis again

we need to have our admin consent together, everyone's data, then we can create ytics

with this kind of data. Okay, let's say that we have an onboarding solution. Whoever is

added in the company, let's say I'm a new employee in company A, when I'm added in Azure

Active Directory, then I want to be automatically added in a Teams group, which is called onboarding

In this case, whenever new subscription is created, we are calling Microsoft Graph from

Azure Functions. This lightning symbol is Azure Functions. When we call Graph API, then Graph validates our app's endpoint, then saves subscription

information in the database. that we can either notify our administrator about the changes, or we can do provisioning

in the external system. External system can be, again, Microsoft Teams or somewhere else

We again call Graph API to do this provisioning. Let's think about a scenario like this

App managers users' calendar and replies the meeting invites. In this scenario, actually, I'm using a real-life reference

So this is the calendar from one of my colleagues, and she is literally working like this every single day

And since she is working with the customers, she does not have any time to check her emails during the day

That's why whenever a new email comes, it directly stays in the calendar, and she sometimes

missed that, and it's really quite a challenge for her. So we were just discussing this, and I built this, and it was really useful and created

lots of impact for others, too. So what we can do in these kind of scenarios, since she doesn't have any time to check teams

and say reschedule this, reschedule that, because it's, again, repetitive function. You can go to Outlook and do the same thing

What we want is the automation and the background system handling the calendar for us

In this case, we build the logic apps, and with logic apps, we are calling Microsoft Graph

to reach out users' calendar, and it is granted by the admin

because end user is not touching anything in the process. What we do is in the calendar

we first of all read whenever new event comes, whenever someone sends an invitation

then we view the calendar of the user. If there is a conflict, simply we call Graph API

API and we response back to the organizer with, if there is no conflict, we reply back

as, okay, we have accepted your event. If there is a conflict, then, again, we turn back to logic apps, we call the Graph API

to check her or him upcoming five days. If it is too busy, like if there are more than 10 events in the calendar, then we say

in the upcoming five days, I'm super busy, so I decline. And if there are less than 10 events in the calendar

then we send a rescheduled request to the organizer. So organizer will be informed that I have availability in upcoming days

So this kind of workflow, we only and only inform end user about what we are doing

So end user has no touch in this kind of workflow. We just send notification to the end user through Microsoft Teams flow bot and end user will have an idea what we are doing

So I'm going to quickly demonstrate how you can do it. let's say that

I can actually share this solution in my GitHub too. I build this flow

and I'm just going to send a calendar invitation by using Graph Explorer

So let's say we have an admin. An admin person is super busy

during the week and he has no time to reply anything and I am as Aychabash is sending the request to the admin and I would like to have a prioritization

meeting. I'm going to run my flow first. Then I'm going to send a request to my admin. I

can actually do that from my own calendar, but I really like using Explorer. Okay. This

This is my request, and this is my admin's email address. I ran the query and post this event in his calendar

And without touching end user, actually, I can show the email here

Since admin has a conflict, it returns that can be rescheduled

Let's check what we had in the flow. So here we see that we have prioritization meeting

And we have another prioritization meeting conflicting with that. So it returns me the can we reschedule because admins calendar actually on those days aren't quite easy

Let me show you. Okay. This is the admin calendar. If I create a request, let's say here, I want to, because it's an empty day, I just want to show you how access and acceptance process works

So what I'm going to do is when I run with Aicha, I'm going to say 8am and I will invite my admin in my company

I send the requests. I need to read on my process. Here is, let's turn back to my mailbox

and I get acceptance. What happens in the background is it's actually checking

in the filter if admin has anything or not. If not, then it directly goes to accept and responds back with the accept

Otherwise, it just goes to, I can show in the designer, it just goes to false because there's a conflict

Then it checks in upcoming five days, admin has how many meetings

If it is more than 10, then it just goes to true

Then it says, sorry, I have lots of meetings in the upcoming days

So I decline. If not, then it just sends the options. Like we want to reschedule to the same day, other times, or later this week or next week

And when all these are happening, admin is only getting, this is my admin

This is my admin. And admin is only getting information like 101 with Aicha, accept it

When am I meeting, reschedule, request it. Everything is just an information level

So my calendar manager running on Logic Apps is just managing everything on behalf of the person, admin

Okay, last but not least, I just want to mention that let the scenario draw your design choice

If your scenario is user interactive, if you're building web app where a user needs to log in and it's like personal stuff, then use delegated permissions

If it is a background process running in the function apps or logic apps in this case

it is just an automation and provisioning scenario it better to use application permissions and app auth Last part of my today presentation is reporting ytics and insights with Microsoft Graph

Let's think about the scenario where we need auditing process, but we are all working from home right now

and we are not at office, so we cannot check how many people are working

how many hours and if they're comfortable working overtime, and so on. So companies auditing processes are really needing these kind of

information. So for this kind of info, we can use Microsoft Graph Data Connect

Microsoft Graph Data Connect has specific data where we can connect by using

Azure Data Factory and we can get user profile messages, calendar events

So these are the specific data we can get and there are some others

And after that, with Azure Data Factory, we can transfer our data to Azure Data Lake or we can directly connect to Azure Snaps for ytics purposes where we can create special queries, let's say, between those days and these people under this group and specific information can be gathered by using Snaps

And if you have any purpose of creating reporting, then you can use Power BI snaps

Azure snaps has a direct connection with Power BI. We can actually show the data from Azure snaps to Power BI automatically

And you can create great charts and pie charts, great information for the business

Another scenario for insights and reporting, if you require more information, let's say, for example

call quality about teams or what's happening in the emails or in the Azure Active Directory in the directory for example how many people get subscription recently if they provisioned to officer sign up provisioned to teams

So these kind of information, if you're looking for, then we can use either logic apps or Azure Functions

Actually, logic apps are the ones we can, if you are looking for a low code environment, logic apps could be your friend

and if you're looking for jobs, then you can use Azure Functions

We can save our data. We can gather our data by using Microsoft Graph

and save the same data in Azure Blob Storage. And then we can transfer data to Data Lake or also Data Factory

With Azure Snaps ytics, we can, again, query data. But these kind of tools are quite important for admin level because sometimes they need specific information

And when a company has hundreds of employees, then this data, like teams or sign-in logs or auditing logs

are easily like millions of data weekly. So to be able to do some queries, searching by the dates or searching by the email address and so on

then the Azure Snaps ytics are a really great tool for us

Again, for the reporting purposes, Azure Snaps ytics has the direct connection with Power BI

Actually, even Azure Data Lake Storage has the connection with Power BI too

If you're looking for reporting and getting some insights about your organization

you can use Snaps Plus Power BI. and with the connection of graph

you can actually gather the entire M365 data. The Dutch I think I kind of over time but these are the documentations I talked to I think that they can be useful if you new to Graph and Azure You can find all of the Microsoft Graph documentation and the

solutions related to Azure under ak.ms slash m-graph. Again, if you would like to play around

a little bit before you implement anything to your app, you can go to Graph Explorer

It's g-explorer. If you want to discover what kind of solutions you can build

there is a great series of blog, which is called 30 Days MS Graph

You can go to aka.ms slash 30 days MS Graph, and you can reach out to all blog series

It's 30 different documentation talking about different scenarios. and Microsoft Graph has a huge GitHub repository open

If you want to search some solutions, if you want to get, for example

chatbot example or React application example, I highly recommend you to go ahead

and check the GitHub repository of the product team. And last but not least, if you have any questions

you can always go to Staker Flow with the tag Microsoft-graph-API. It's an up-to-date tag

You can always ask your questions there, and we will try to answer all of them

And thank you so much for joining my session today. If you have any questions about my presentation or you want to learn something specific about what I taught today or something related to graph and Azure, you can always reach out to me from Twitter

and if you tweet it I can try to answer it back too