Koppelingen op Microsoft Graph: wat de storing leert over maatwerksoftware

Wat er met Microsoft Graph gebeurde

Microsoft Graph is de API waarmee software buiten Microsoft met Microsoft 365 praat. Wie een mail laat versturen vanuit een eigen systeem, afspraken in een agenda zet of gebruikers en teams beheert, doet dat meestal via Graph. Op de statuspagina van Microsoft meldt Microsoft dat Graph-verzoeken die bij Exchange Online-gegevens komen, zoals mail, agenda en contactpersonen, kunnen verlopen. Dat raakt ook het beheer van teams, kanalen, leden en apps, en het versturen van meldingen in Teams via Graph.

Het bleef niet bij interne bedrijfssoftware. Volgens ITdaily meldden ook Anthropic en OpenAI dat de koppelingen van Claude en ChatGPT met Microsoft 365 niet werkten. Dat laat zien hoe breed Graph gebruikt wordt: elke dienst die namens een gebruiker in Microsoft 365 kijkt, heeft deze laag nodig.

Is uw eigen software geraakt?

Niet elke koppeling merkt de storing. Microsoft noemt Graph-verzoeken naar Exchange-gegevens; een koppeling die alleen bestanden in SharePoint leest, kan gewoon werken. Kijk per koppeling welke gegevens hij gebruikt. Hoe de diensten zelf geraakt zijn, staat in de artikelen over Teams en Intune, Defender en Copilot.

Typische koppelingen en de kans dat ze geraakt zijn, naar de melding van Microsoft, stand 13 november 2026, 10.15 uur

De snelste manier om het te weten: kijk in de logboeken van uw software naar fouten richting graph.microsoft.com sinds donderdagmiddag 12 november. Een plotselinge stijging van verlopen verzoeken, foutcodes in de 500-reeks of meldingen dat Graph het verzoek afremt, wijzen op de storing. Heeft u geen logboek dat dit laat zien, dan is dat op zichzelf al een les.

Ontwerpkeuzes die het verschil maken

Een koppeling met Microsoft 365 gaat er stilzwijgend van uit dat Microsoft er altijd is. Meestal klopt dat. Maar software die gebouwd is voor de dag dat het niet klopt, voorkomt dat een storing bij Microsoft ook een storing in uw eigen proces wordt. Het gaat om een paar keuzes die in elke goede koppeling horen.

1. Opnieuw proberen, met geduld

   Bij een fout niet meteen opgeven en niet blijven hameren. Opnieuw proberen met steeds langere tussenpozen, en de aanwijzingen van Graph over wachten respecteren.

2. Werk in een wachtrij zetten

   Een mail of afspraak die nu niet lukt, gaat in een wachtrij en wordt verwerkt zodra Microsoft weer antwoordt. Niets gaat verloren, niemand hoeft het opnieuw in te voeren.

3. De gebruiker eerlijk informeren

   Laat zien dat iets later wordt verstuurd in plaats van een technische foutmelding of een draaiend wiel. Dan weet de gebruiker waar hij aan toe is.

4. Het kernproces los houden

   Een order aannemen of een rooster maken moet doorgaan, ook als de bevestiging per mail even wacht. Maak Microsoft 365 een kanaal, niet het fundament van uw proces.

Na het herstel: wat u nakijkt

Als Graph weer normaal antwoordt, komt het belangrijkste werk: nagaan wat er tijdens de storing is misgegaan. Zoek in uw logboeken naar verzoeken die definitief zijn mislukt. Een mail die nooit is verstuurd, een afspraak die niet in de agenda staat of een synchronisatie die halverwege stopte, merkt niemand op tot een klant belt.

Let ook op het omgekeerde: software die tijdens de storing bleef proberen, kan na het herstel dubbel versturen of dubbel boeken. Controleer of uw koppeling voorkomt dat dezelfde actie twee keer wordt uitgevoerd. En kijk of de storing een blinde vlek liet zien in uw meldingen: wist u dat er iets mis was voordat gebruikers het zeiden?

Voor de bredere vraag hoe afhankelijk uw processen van één leverancier zijn, leest u het artikel over afhankelijkheid en bedrijfscontinuïteit. Wilt u weten hoe Appfront koppelingen met Microsoft 365 bouwt, kijk dan bij Microsoft 365-koppeling laten maken. Voor de tijdlijn van de storing leest u het overzicht van de storing.