Skip to main content

What breaks when an Outlook calendar event doesn't sync to an attendee?

A close-deadline event created through Loopfour's Outlook integration under application permissions is created successfully but silently invisible to attendees — Microsoft's own Graph documentation confirms no email is sent and the event doesn't show up in the attendee's or organizer's calendar under that auth model. The API call succeeds; nobody gets reminded.

Zuny FesterBy Zuny Fester, Head of Operations and Marketing
Reviewed by Zuny Fester
Published Last reviewed Editorial policy

Part of the finance integrations guide.

SymptomcreateEvent returns success, but the responsible person never sees a deadline reminder
Root causeThe integration is authenticating with application permissions, not delegated
What Microsoft's own docs say"No email is sent to attendees, and no event shows up in their calendars" under application permissions
Where else this bitesShared/delegated calendars the acting identity doesn't actually have access to
How to tellCheck the auth flow the integration is running, not the API response — the call itself won't error

Why this fails silently

This isn't an error state — createEvent returns a successful response with the new event's ID whether or not any attendee actually sees it. Microsoft's own documentation on creating events in shared and delegated calendars states the gap directly: under application permissions, an event technically gets created, but no email is sent to attendees, and no event shows up in their calendars. A workflow that only checks the API response for success has no signal that this happened.

The second way this shows up: calendar access that was never actually granted

A related but distinct failure: posting to another user's calendar requires that calendar to actually be shared or delegated to the acting identity — Microsoft's guidance is explicit that even an admin with tenant-wide privileges can't reach another user's calendar without that relationship configured, delegated permission alone isn't enough. An attempt against a calendar that was never shared can fail at the access-check stage before an event is even created, which is a different failure mode from the application-permissions case but produces the same symptom for the end user: no deadline shows up.

How to catch it before it matters

Don't rely on createEvent's success response as proof anyone was actually notified. Confirm the integration is running under delegated permissions (a signed-in user context) rather than application-only auth for anything that needs to reach an attendee, and for shared calendars specifically, verify the sharing/delegation relationship exists before the first close cycle depends on it — not after someone misses a deadline they never saw.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A close deadline that 'exists' and reaches no one

A Loopfour workflow calls createEvent to post "Intercompany eliminations due" to a controller's Outlook calendar, with the controller listed as an attendee. The Graph API returns 201 Created with a new event ID — everything about the response looks correct. Three days later, close is delayed because the controller never saw the deadline: the integration was authenticating with application permissions, so per Microsoft's own documented behavior, the event was created in the abstract but never emailed to the controller and never appeared on their calendar. The fix isn't retrying the call — it's switching the integration's auth flow to delegated permissions, which is what actually triggers attendee notification.

Frequently Asked Questions

No — the call succeeds and returns the created event's ID under either permission model. There's no error response signaling that attendees weren't notified; it has to be caught by knowing which auth model is in use, not by inspecting the response.

This diagnostic is specifically about event creation and attendee notification under application vs. delegated permissions, as documented for the Outlook/Calendar API — other Graph resources (mail, files) have their own permission-model nuances that aren't the same failure.

Check the OAuth flow and token type the integration authenticates with — a client-credentials flow (no signed-in user) is application permissions; an authorization-code flow tied to a specific user's sign-in is delegated. The API response alone won't tell you.

Sources

Related

How-to

What should be on a month-end close checklist?

A complete close checklist covers subledger lockout, bank and balance-sheet reconciliations, accrual entries, intercompany revaluation and elimination if applicable, inventory review if applicable, consolidated review, and period lock. Each task should have a clear owner and a place in the dependency order, not just a due date.

Read more

Topic

Integrations

Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…

Read more

How-to

How do I track close checklist sign-off using Slack reactions?

Post each close checklist item as its own message, then have the responsible person react to it with an agreed emoji to signal sign-off. Loopfour's Slack integration reads that back via reactions.get, which returns a users array naming who reacted — but Slack's own docs warn that array can be incomplete, so treat it as a strong signal, not a guaranteed audit trail.

Read more

How-to

How do I add month-end close deadlines to Outlook calendars?

Call Microsoft Graph's createEvent (POST /me/events or /users/{id}/events) with the deadline as start and end, and each responsible person listed in the attendees array. Graph is explicit that this only reliably notifies attendees under delegated permissions — application permissions can create the event without ever emailing or showing it on an attendee's calendar.

Read more