Microsoft 365 for Frappe: Outlook Calendar Sync, Teams Meetings, Recordings & Transcripts

Frappe Framework App Development
, , ,
1

As a Frappe/ERPNext implementation company, we work with many organizations using Microsoft 365, and we use it internally as well.

A common challenge we faced was that Frappe’s built-in calendar integration is primarily for Google, while many of our clients use Outlook and Teams. This meant Frappe Events and Outlook calendars were essentially living in two different places.so we built integration

frappe_microsoft365

https://github.com/Bizmap-Technologies-Pvt-Ltd/frappe_microsoft365

What it supports

  • Two-way Outlook Calendar ↔ Frappe Event sync

  • Delta-based sync to handle recurring events, updates and deletions without duplicates/orphans

  • Teams meetings directly from Frappe Events, with the join link added back to the Event

  • Accept / Tentative / Decline invitation responses

  • Teams meeting recordings and transcripts, linked back to the Event

  • Transcripts automatically attached as .vtt

  • One Entra/Azure app registration per organization, with individual user authorization

A few things to know

Default calendars only: Shared mailboxes, room calendars and shared calendars aren’t supported yet.

Email stays native to Frappe: The app doesn’t replace Frappe’s Email Account functionality. It helps configure the Microsoft Connected App for Outlook OAuth, while Frappe continues handling email normally.

Teams transcripts: Microsoft requires an additional tenant-level setting/policy for transcript access. Without it, Graph can return a 403 even when permissions and consent are correct.

We built this to solve a recurring requirement across our Frappe implementations and thought it could be useful to the wider community.

It’s open source, and contributions, issues, feedback and suggestions are welcome.

We’d also love to know what would be useful next shared/room calendars, deeper Teams integration, SharePoint, OneDrive, or something else?

2

This looks very useful, especially for organizations already standardized on Microsoft 365. The two-way Outlook sync and Teams integration address a real gap in Frappe.

3

Hi Suraj,

really interesting project — and interesting timing for me as well.

I have been working on a public Microsoft 365 integration for Frappe too:

It originally grew out of our own service platform, OneTokenSite, but the direction is slightly different from frappe_microsoft365.

Your project currently looks much stronger around:

  • two-way Outlook Calendar sync
  • delta processing
  • recurring events
  • Teams meetings
  • recordings and transcripts

My current work has been more focused on building a broader Microsoft 365 integration layer for Frappe, including:

  • personal / shared / team / resource calendar concepts
  • Microsoft Bookings
  • and SharePoint as a likely next module

One important note: while the calendar account model already supports different calendar usage types, I would still consider real shared mailbox / cross-user calendar support something that needs more tenant-level testing before claiming it as fully solved.

Your question about shared/room calendars, SharePoint and OneDrive is exactly what caught my attention.

I wonder if there could be value in coordinating instead of building two completely separate Microsoft Graph integration stacks.

A broader Frappe M365 architecture could perhaps have a common foundation for:

Microsoft / Entra Account
        ↓
Common Graph/Auth layer
        ↓
├── Outlook Calendar
├── Shared / Room / Resource Calendars
├── Teams
├── Bookings
├── SharePoint
└── OneDrive

with the individual features remaining modular.

I am not suggesting that one project should simply be replaced by the other — both seem to have useful work in different areas. But it may be worth comparing the authentication/account model, permissions, delta-sync approach and Graph abstractions to see whether some parts can be shared or aligned.

If you are interested, I would be happy to compare the architectures and see whether there is a sensible way to collaborate.

4

I’m very interested in the MS Teams integration and using it’s Sharepoint backend for storage. I’ve gone ahead and forked the existing code on github and will continue to build out for a current implementation needs.

5

Hi,

Thanks, and agreed. Two separate Graph stacks for Frappe would be a waste, and our projects complement each other well: you have Bookings, the shared/resource calendar model and the account split, and we have two-way delta sync, recurrence, Teams, transcripts and the setup doctor

Since frappe_microsoft365 already has the larger tested base (412 tests, CI on v15/v16), I’d suggest using it as the common foundation and adding Bookings and shared calendars as modules on top. Two pieces we’re about to build line up closely with your work: separating the Microsoft account from the calendar, and an

app-only (client credentials) path for background jobs. Your input on both would be very welcome.

@eleben is also starting on SharePoint storage on a fork, so this is a good moment to align all three efforts.

Happy to compare architectures. Shall we start with the auth/account model?

6

I have a working example for the Teams integration for storage, feel free to check it out and test.

GitHub - eleben/frappe_microsoft365: Microsoft 365 for Frappe and ERPNext — Outlook calendar two-way sync, Teams meetings, transcripts, SSO. · GitHub - feature/sharepoint-files branch

7

Hi Suraj,

yes, starting with the auth/account model sounds like the right next step.

I had a closer look at my current grx_M365 implementation, and I think the main areas we should compare are:

  • separation of Microsoft account / tenant from calendars and other resources
  • delegated OAuth vs. app-only / client credentials
  • background jobs without depending on an interactive user session
  • personal, shared and resource calendar handling
  • how Bookings fits into the same Graph/auth layer
  • keeping the common foundation Frappe-first, without a hard ERPNext dependency

One architectural point that is particularly important for my use cases is that a Microsoft user/account should not necessarily be the same thing as the resource being integrated.

In grx_M365, calendars are already separate M365 Calendar Account records, and Bookings businesses are separate resources as well. The app-only Bookings path is also deliberately independent of an interactive Microsoft user session.

That becomes important for shared calendars, rooms/resources, Bookings and probably SharePoint later on, where there may not be a meaningful 1:1 relationship between a Frappe User, a Microsoft User and the actual Microsoft 365 resource.

I should also be clear that my shared/resource calendar support is not something I would claim as fully solved yet — the model is prepared for it, but the actual Graph/runtime behaviour still needs more tenant-level testing.

Your planned work on separating the Microsoft account from the calendar and adding an app-only path for background jobs therefore lines up very closely with what I already have or need.

Given your existing tested base, delta sync, recurrence handling, Teams integration and v15/v16 CI, I think frappe_microsoft365 could very well be the stronger common foundation. I’d just prefer to compare the models first and make sure these broader resource/account use cases fit cleanly before changing code on either side.

Also great to hear that @eleben is already working on SharePoint. If we can align the common Graph/auth foundation first, it would be much better to have Calendar, Teams, Bookings and SharePoint as modules on top of one shared base instead of growing separate Graph stacks.

My contribution would most likely be around the areas I already have or actively need:

  • Bookings
  • app-only / client credentials
  • account/calendar separation
  • shared/resource calendar requirements
  • keeping the integration usable on plain Frappe

I’ll put together a short architecture summary from grx_M365 and share it here. Then we can compare both approaches and decide on the next small step.

8

Hi Suraj,

I went through the current grx_M365 architecture in a bit more detail and put together a short collaboration summary here:

The main area I think we should compare first is the auth/account/resource model.

In particular:

  • separation of Microsoft authentication/account context from Calendar and other resources
  • delegated OAuth vs. app-only/client credentials
  • background jobs without depending on an interactive Microsoft user session
  • shared / room / resource calendar requirements
  • Bookings as an optional module
  • keeping the common base usable on plain Frappe without a hard ERPNext dependency

I also tried to be explicit about the current limits of grx_M365: shared/resource calendars are prepared in the model, but I would not claim them as fully implemented or tenant-tested yet.

From what you described, frappe_microsoft365 looks like the stronger existing base around two-way calendar sync, delta handling, recurrence, Teams and testing. My main interest would be to see how your planned account/calendar separation and app-only work could line up with the Bookings and resource-model work I already have.

I added a short list of architecture questions at the end of the document. If the models line up, I think that gives us a good basis for deciding the first small contribution.