Microsoft Graph Change Notifications - Simply Explained

Today's topic is one that almost everyone building with Microsoft 365 has heard of, but most people don't really get how it works behind the scenes. I'm talking about Microsoft Graph change notifications. What exactly are they? And why should you care? Let's start with the problem they solve. Imagine you build an app that needs to know when something changes in Microsoft 365, maybe a new email arrives, someone updates a file in SharePoint, or a new user gets added to your company directory. How does your app find out? Here's the thing, the old way is polling. Your app sends a request to Microsoft Graph every few minutes and asks, "Anything new since I last checked? If nothing changed, you wasted a request, and if something changed five seconds after your check, you won't know until the next cycle." You're either checking too often, wasting resources and risking throttling, or too rarely, which means you miss things. Microsoft actually throttles apps that poll too aggressively, developers call it GraphJail, and your app gets blocked for a while because it's making too many requests. So the question becomes, "Isn't there a better way?" What if instead of your app constantly asking anything new, the system just told you when something changed? That's exactly what change notifications do. What are Microsoft Graph change notifications? Here's the simplest definition, change, notifications, let your app react instantly to events in Microsoft 365 without constant checking. Think of it like a motion sensor on your mailbox. Instead of walking past it every hour to peak inside, you install a sensor that pings you the moment mail arrives. You stop wasting time when empty checks are never miss a delivery. That's what change notifications do for your app. When something changes, like a new email, an updated file or a calendar event, Microsoft Graph sends a notification to your app automatically, no polling required. Now this system has two pieces, a subscription and a notification, and they work together. The subscription is where you tell Microsoft Graph what you want to watch. You say things like, "Hey, let me know when someone sends a new message to this inbox," or "Tell me when a file gets updated in this SharePoint library." You register your interest and Graph takes note. The notification is what happens next. When the change occurs, Graph sends an HTTP post to an endpoint you provide. Your app receives that post and knows something happened, and it can then decide what to do, like fetch the new data, trigger a workflow, or update a database. Here's the key difference from polling. Notifications are delivered automatically. Your app doesn't have to ask, the system pushes the information the moment it happens. That's the magic of it. Microsoft Graph supports change notifications for a wide range of resources. Messages, events, contacts, users, groups, files, teams, messages, security alerts, pretty much anything you can access through Graph can be monitored for changes. But how do you actually set this up? How do you tell Graph what to watch and where to send the alerts? Creating a subscription, telling Graph what to watch. So what is a subscription? It's just a registration request. Your app says, "Let me know when this thing happens," and you send that request to the Microsoft Graph API. Graph stores it and waits. You need to give Graph a few details in that request. First, the resource you want to watch. The path to the data. For example, then users if you're monitoring changes to user accounts or me, male, folders, inbox messages if you want to know about new emails. Next, the change type. Do you want to know when something is created, updated, deleted? You can pick one or you can ask for all three. Third, the notification URL. This is your endpoints address. The place where Graph should send the notification when something happens. It has to be a publicly accessible HTTPS endpoint. No shortcuts there. Fourth, the expiration date. Subscriptions don't last forever. You pick a future date in time when the subscription expires. But different resources have different max lifetimes. Outlook messages can last up to seven days. Teams chat messages max out at three days. SharePoint files can last about 30 days. Present information? That expires after just one hour. Here's a concrete example. Say you want to know when someone in your company changes their job title. You create a subscription for the user's resource with a change type of updated. You point it to your notification URL and set the expiration a few days out. When someone updates their profile in Enter ID, Graph sends a post to your endpoint with a notification payload. That payload includes the user's ID and tells you what changed. Your app can then act on it, update an HR system, trigger a notification to their manager, whatever you need. Graph responds to your subscription request with a subscription ID. You'll need that ID later to manage the subscription, renew it, update it, or delete it. But here's the thing. Before Graph starts sending notifications, it needs to confirm your endpoint is actually alive and listening. That requires a handshake. The handshake. Validation token explained. When you create a subscription, Microsoft Graph doesn't just trust your endpoint blindly. It sends a test ping first, a verification request. That ping includes a validation token, a random string of characters. Your endpoint has to catch that token and send it back as plain text within 10 seconds. Think of it like a delivery driver ringing your doorbell to confirm your home before leaving a package. If nobody answers, the driver leaves nothing. Same here. If your endpoint doesn't echo back the validation token, Graph won't send notifications to it. The response must be plain text, not JSON or XML, just the raw token string. Get the format wrong and the handshake fails. It's a security check. It proves your endpoint is alive, listening, and under your control. It stops someone from pointing a subscription at a URL they don't own, hoping to intercept notifications meant for someone else. No handshake means no subscription. Graph rejects the creation request and you get an error. You fix your endpoint and try again. Once the handshake succeeds, the subscription is active and notifications start flowing. But here's the thing. They don't flow forever. Keeping the connection alive. Subscription renewal. Every subscription has an expiration date. You set it when you created. Graph enforces it. When that date arrives, the subscription stops. No more notifications. Think of it like a parking meter. You put in the time and when it runs out, the meter flags expire. Different resources have different limits. Outlook messages can run for seven days. Teams chat messages three days. SharePoint files last about 30 days. Presence information. Just one hour. So your app can't just create a subscription and forget about it. You need a process that keeps it alive. Renewing is simple. Send a patch request with the subscription ID. Include a new expiration date. Do it before the current one expires. And graph extends the subscription. Here's the best practice I recommend. Check the expiration timestamp on every notification you receive. If it's close to expires, say within a day, renew it right then. That way you don't need a separate background job just to manage subscriptions. Microsoft also added life cycle notifications. These alerts warn you before a subscription expires. They tell you when your subscription is about to end or when your access token needs reauthorization, subscribe to these and your app can renew before anything breaks. But what if your endpoint goes down? Or you miss a renewal window? That's where the safety net comes in. When things go wrong, reliability and safety nets. Your subscription is active. Your endpoint is listening. Notifications are flowing. Everything looks good. But what happens when something breaks? Maybe your endpoint goes down for maintenance. A network issue drops a notification. Or you simply miss the renewal window and the subscription expires. These things happen. The question is, how do you recover? Microsoft Graph expects your webhook endpoint to respond quickly within three seconds. If it takes longer, Graph marks it as slow. If more than 10% of your responses exceed three seconds in any 10-minute period, Graph delays your notifications by 10 minutes. It sends only a small sample to check if you've recovered. It gets worse. If more than 15% of your responses exceed the 10-second retry timeout, Graph marks your endpoint as drop. Notifications stop entirely for 10 minutes. They're gone. You can't get them back. So your endpoint needs to be fast and reliable. That doesn't mean you have to process every notification in under three seconds. Just acknowledge receipt quickly with a 202 accepted response. Then process the notification asynchronously, queue it up, handle it later. The key is that fast response. Even with a perfect endpoint, things can still go wrong. Subscriptions expire. Network blips happen. Microsoft Graph itself might miss a notification in rare cases. That's why you need a safety net. Delta queries. Think of it this way. Change notifications are the fire alarm. They tell you something is happening right now. Delta queries are the sprinkler system. They catch anything the alarm missed. They work together. Notifications give you real-time awareness. Delta queries give you a complete picture you can reconcile at any time. The recommended pattern is simple. Use change notifications for instant awareness. Run a Delta query periodically. Maybe every few hours or once a day to catch anything that slipped through. This way, even if a notification was lost or a subscription expired, you never miss a change permanently. Real-world use cases. What you can build. So what does this actually enable? Let me walk you through some real examples. Take HR automation. Imagine someone joins your company tomorrow. The moment EntraID creates a new user a change notification fires. Your app grabs their profile and creates accounts in your HR platform. Time tracking and building access. All in seconds, no polling, no delays. For security alerts, say a user's account gets disabled. A change notification triggers a workflow that checks for suspicious changes and alerts your security team before you'd pull every few minutes. Now it's instant. Content processing works the same way. When a file lands in a SharePoint document library, you want to know if it's an invoice. The notification tells you a new file exists. Your app grabs it, runs it through AI to classify it and sends it to the right expense system. All automatic. Real-time dashboards let you see analytics as they happen. Not from hours ago. Change notifications. Sync dataverse to fabric instantly. Your Power BI dashboards update in near real-time. Here's one I find interesting. Co-pilot connectors. Microsoft adds real-time sync through webhooks so AI agents respond the second data changes. When a customer records updates in Dynamics 365, a co-pilot agent generates a follow-up immediately. No waiting. All these examples share one thing. Before change notifications, you build scheduled jobs that hold every hour or day. It worked, but was slow, wasteful, and fragile. Change notifications, flip that model. Real-time, event-driven, instant. Choosing the right delivery channel, not every app needs the same delivery. Let's look at your options. Webhooks are the simplest. Graph sends an HTTP post to your endpoint. You process it and move on. For low-to-medium volumes, say a few hundred notifications an hour, that works fine. But what if you're building something bigger? Thousands of notifications per second can overwhelm a single endpoint. You need something more powerful. Event hubs handles millions of events per second. Instead of graph sending notifications one by one, it sends them to a hub. Your app reads at its own pace. No risk of flooding. This is for large enterprise scenarios like thousands of SharePoint sites or millions of mailboxes. Then there's Event Grid, the serverless option. It sends notifications to Azure Functions or Logic Apps and automatically handles retries and dead lettering. If you're building automated workflows in the cloud and don't want to manage servers, Event Grid is your friend. Here's how you decide. For simple, low-to-medium volume, Webhooks. Need massive scale? Event hubs, serverless automation, Event Grid. But remember, all three require a subscription. The difference is how notifications arrive, not whether they arrive. Same core concept. Subscribe, listen, renew. So what's the big picture? Change notifications are the alert system that makes Microsoft 365 reactive. You subscribe to tell Microsoft Graph what to watch, listen for notifications on your endpoint and renew before the subscription expires. It's that handshake between you and the cloud. But what if you miss a notification? Delta queries are your safety net. They catch you up on everything that changed. Notifications give instant awareness. Delta queries give complete reconciliation. Together, they ensure nothing gets lost. Best way to understand it? Start small with Graph Explorer. Subscribe to your own inbox. Watch the notification arrive and see the handshake happen. That's the quickest path. That's change notifications in plain English. I'm Mirko Peters from M365. FM, subscribe and share. We'll see you next time.