How Odoo and Microsoft 365 integration works for mail, calendar and sign-in
Your staff need to send and receive mail from Odoo, keep their calendars in step with it, and sign in with their Microsoft 365 accounts. These are separate connections, not one setting. Each one uses Microsoft Azure OAuth and needs its own Entra ID app registration, so a working mail connection does not confirm that calendar sync or Microsoft sign-in will work. Plan, register and test each connection on its own before you tell users the integration is ready.
This page covers four parts of the work: outgoing mail, incoming mail, Outlook Calendar synchronization and the Outlook mail plugin, plus Microsoft sign-in as a way into Odoo. Outgoing and incoming mail are configured in Odoo's mail settings, while the calendar, plugin and sign-in options sit in different places depending on the app and release. The exact settings also depend on your Odoo edition, your hosting type (Odoo Online, Odoo.sh or on-premise) and your Odoo version. Confirm each step in the documentation for the release you run, because menus, option names and supported features change between versions.
Several decisions shape the build before anyone opens the Azure portal. Decide which Entra ID tenant owns each app registration and who holds administrator consent for the permissions each connection requests. Confirm the redirect URI that Odoo expects for your base URL, since a mismatch is a common cause of failed sign-in and token errors. Decide whether mail will flow through shared mailboxes or individual user mailboxes, and confirm that your hosting type allows Odoo to reach Microsoft's endpoints and, where needed, to receive inbound mail. Write these answers down, because they determine the app registrations you create.
Before go-live, record for each of the three connections the app registration name, its owner, the credentials it uses and the date those credentials expire. An expired client secret often fails quietly, and users may only notice when mail stops leaving Odoo or a calendar stops updating. Test each connection with a pilot group, including a sign-in from a user who is not an administrator. Ask your implementation partner, if you use one, to deliver these records and the tested configuration as part of the written scope, so your team can run the integration after handover.
What you need before configuring Microsoft 365 in Odoo
Microsoft 365 connections in Odoo depend on decisions made before anyone opens the settings page. Your Odoo edition, hosting type and version set which features exist and how long they receive fixes. Your tenant, public address and network paths determine whether Microsoft can complete sign-in and token exchange.
Odoo edition
Odoo Community is open source under LGPL-3.0, while Enterprise adds features and support, and its source code is not publicly available. Enterprise requires a subscription or partner access, and on-premise Enterprise databases are activated by entering the subscription code. Confirm which edition you run, then ask Odoo or your partner to confirm, feature by feature, whether each Microsoft 365 capability is included in that edition.
Hosting type and plan
Odoo Online, Odoo.sh and on-premise each assign different owners to servers, upgrades and backups. According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. The One App Free and Standard plans are Odoo Online only. Confirm your plan before designing the integration, because the hosting type limits which plan you can use.
Odoo version and support window
Odoo 19.0, released in September 2025, has standard support until September 2028, and Odoo 20.0, released in September 2026, has standard support planned until September 2029. Odoo 18.0 is supported until September 2027, while Odoo 17.0 standard support ended in September 2026. Standard support includes security updates and bug fixes, and security patches are provided only during that window. Confirm your version's end date before you schedule the Microsoft 365 work.
Microsoft 365 tenant and admin rights
The integration needs a Microsoft Entra ID tenant that holds the mailboxes or calendars you plan to connect, plus an app registration created inside that tenant. A person with rights to consent to application permissions must approve the scopes for your organization. Ask your Microsoft 365 administrator which role your tenant policy requires and whether user consent is restricted. Confirm the exact permission scopes for each feature in the Odoo documentation for your version.
Public HTTPS address for redirect URIs
Microsoft returns users to Odoo at a redirect URI registered in the app registration, so Odoo must answer on a public HTTPS address that matches that URI exactly. Choose the hostname, TLS certificate and path before you register the app, since changing the address later means updating each registration. Confirm the redirect URI format each feature requires in the Odoo documentation for your version. Test the address from outside your network before you rely on it.
Outbound network paths for self-hosted servers
Self-hosted Odoo servers must reach Microsoft sign-in, token and API endpoints over outbound HTTPS, and some mail flows may also need SMTP or IMAP paths. Firewalls, proxies and DNS rules can block these paths without an obvious error in Odoo. Ask your network team to build the endpoint list from the Odoo documentation for your version and Microsoft's current published endpoints. Test each path from the Odoo server itself, not from a workstation.
Which Microsoft 365 connection each Odoo feature needs
Each Microsoft 365 feature you plan in Odoo uses a different part of the Microsoft identity and mail model, so each one can need its own app registration in Entra ID, its own API permissions and its own redirect configuration. Outgoing mail, incoming mail, calendar synchronization, the Outlook mail plugin and Microsoft sign-in touch different objects: a mailbox that sends on behalf of a user, a mailbox or alias that receives messages, a user's calendar, an add-in deployed through Microsoft's administration tools, and the sign-in flow for Odoo users. Treating them as one connection is a common planning error, because a registration that works for sign-in may not carry the mail or calendar permissions the other features need, and the redirect addresses that satisfy one feature may not match another.
Start with a written list of the features your project needs, then decide which ones are in scope for the first release. For each feature, record the Microsoft object it reads or writes, who owns that object, which users it covers, and whether it is needed at go-live or later. A mailbox used for customer correspondence, a shared sales calendar and a staff sign-in can each look like a single line on a requirements list, yet each leads to a different owner, consent step and test. Scope decisions made here drive the app registrations later, so a broad item such as "email" should be split into outgoing and incoming mail before anyone creates a registration. Keep the list in the same document as the Odoo version and edition you intend to run.
Next, confirm for every feature which mechanism the Odoo documentation for your exact version describes. Some features are documented as Azure OAuth configuration, some as a separate connector published through the Odoo Apps Store or the Odoo Community Association, and some as a plugin with its own deployment path. Odoo's documentation lists Microsoft Azure OAuth among its user sign-in options, which is a different use from mail or calendar access, so a working sign-in setup does not by itself confirm that the other features are covered. Check each feature's page in the documentation for the version you run, and record the version and the page you used, because guidance can change between releases.
Do not promise any feature to stakeholders until that check is complete and written down. Ask the Odoo partner or your internal team to confirm, for each feature, the edition that includes it, whether it is supported on your hosting type, the Microsoft permissions it requires, and whether a tenant administrator must grant consent. For connectors and plugins, check who maintains the module, which Odoo versions it supports and what its license terms allow. If a feature cannot be confirmed for your edition, record it as an open item with a named owner and a decision date, and plan the registration work around the features that are confirmed.
Configuration sequence for Odoo and Microsoft 365
This sequence takes an Odoo instance from its hosting setup to a working Microsoft 365 connection for mail, calendar, the Outlook plugin and sign-in. Each step ends with a check, so a fault is found before the next layer depends on it. Confirm the menu paths for your Odoo version with your implementation partner, because the screens change between releases.
Confirm edition, version and hosting
Confirm which Odoo edition, version and hosting type you run, and who holds the subscription. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that plan includes external API access and custom modules, which some connector setups depend on. Check that your version is inside its standard support window. Odoo 19.0 standard support runs until September 2028, so an older release may need an upgrade before you start. This step is done when an administrator can open the version and subscription details and the team has written down the hosting type for the rest of the sequence.
Fix the public base URL and HTTPS certificate
Set the public base URL in Odoo to the exact address that users and Microsoft will reach, served over HTTPS. Microsoft returns sign-in and OAuth callbacks to that address, so an internal host name or a mismatched address breaks every later step. Confirm the certificate is valid, trusted by clients outside your network and covers the host name in the base URL. Check: open the base URL from a browser outside the corporate network, confirm the Odoo login page loads with a valid certificate, and confirm the same address appears in the Odoo system configuration.
Register each Entra ID application
In Microsoft Entra ID, register one application for each function: outgoing and incoming mail, calendar sync, the Outlook plugin and sign-in, unless the design confirms that one registration covers several functions. Enter the redirect URI that Odoo shows for each function exactly, including scheme and path. Add only the Microsoft Graph permissions that each function requires, and confirm them against Odoo's documentation for your version. Record the application ID and tenant for each registration. Check: every registration lists its redirect URI and permissions, and the list matches the written design.
Grant admin consent for the permissions
A tenant administrator grants consent for the permissions requested by each application. Tenant policy often limits who can approve application-level permissions, so agree this step with the Entra ID owner before the build starts. Confirm that consent is granted for every permission on every registration, and record any permission that remains pending as a blocker with an owner. Check: the API permissions view in Entra ID shows a granted status for each permission on each registration, and the approval is recorded in your change ticket.
Enter client identifiers and secrets in Odoo
Copy each application's client ID and create a client secret, then enter both in the matching Microsoft settings in Odoo. Store each secret in your secrets manager as the source of record, and add its expiry date to your renewal calendar. An expired secret stops mail and calendar sync, and Odoo may not show a clear error for it, so the expiry date needs an owner. Restrict access to these settings to named administrators. Check: save each configuration, confirm Odoo accepts the values without a validation error, and confirm the renewal date is recorded.
Configure outgoing mail, then incoming mail
Configure outgoing mail first, because it is the simplest check and the one most later steps depend on. Send a test message from Odoo to a mailbox you control, then confirm it arrives with the expected sender and without authentication warnings in the message headers. Next, configure incoming mail, which routes replies and new messages back into Odoo records. Check: send a message from an external mailbox to the incoming address and confirm it appears in the linked Odoo record. Do not move to calendar sync until both directions pass.
Enable calendar sync and the Outlook plugin
Turn on calendar synchronization using the calendar registration from the earlier step. Create an event in Odoo and confirm it appears in the test mailbox's Outlook calendar with matching times, then create an event in Outlook and confirm it appears in Odoo. Once the two-way check passes, install the Outlook plugin on one pilot user's computer and sign in with the same test account. Check: events appear on both sides, and the plugin shows the linked Odoo records for the test user. Confirm the plugin deployment method with your device management team before wider rollout.
Test Microsoft sign-in with a test account
Enable Microsoft sign-in last, then test it with a dedicated account in a private browser session so that cached sessions do not hide errors. Confirm that the account maps to an existing Odoo user, or that the user creation behavior you chose creates the expected account. Check that the sign-in completes from the browser, that the user lands in the correct company, and that sign-out and a second sign-in both work. Record the result in your test log and keep the test account for regression checks after future upgrades.
How Microsoft 365 identities and items map to Odoo records
This table compares each Microsoft 365 item with the Odoo record it lands in, the key used to match it, and the decision to settle before go-live. Read the matching key column first, because a changed UPN or email can create a duplicate Odoo user. Items marked as checks need confirmation against the Odoo version, sign-in method and company setup you run.
| Microsoft 365 item | Odoo record | Matching key | Decision for the reader |
|---|---|---|---|
| User principal name (UPN) | Login on res.users, the user's sign-in name | Sign-in name. Check whether matching is case-sensitive and whether Odoo accepts UPNs as logins | Decide whether UPN or primary email is the login identifier |
| Primary email address | Email on the linked partner record, and the login if configured that way | Email address. Check that each address maps to one active user | Decide whether email is the key for matching existing users |
| Entra object ID | No standard field confirmed. Check whether a custom field is needed for your Odoo version | Stable directory identifier that does not change when a UPN or email changes | Decide whether to store the object ID or match on email alone |
| Mailbox (user or shared) | Outgoing or incoming mail account configured against the sending or receiving address | Mailbox address. Check the Azure OAuth consent and delegated access for each mailbox | Decide which mailboxes Odoo may send from or read |
| Calendar | calendar.event records linked to the organizer user and attendee partners | Attendee email matched to a partner. Check how events are identified on each sync | Confirm sync direction and which calendars are included per user |
| Group membership | Access groups on res.users. Company membership on res.company needs the Custom plan | Group name or object ID mapped through a rule you define. Check the rule syntax for your version | Decide whether groups come from a first sign-in template or from administrators |
| Shared mailbox or mail alias | Mail alias (mail.alias) routing incoming mail to a model, such as a sales or helpdesk record | Alias address. An alias identifies a route, not a person | Decide whether an alias creates records or only routes messages |
How to test mail, calendar and sign-in before go-live
Write the test plan before anyone sends a message. Name a pilot group of users who depend on mail, calendar and sign-in every day, and create dedicated test mailboxes in Microsoft 365 that no one uses for customer correspondence. Give each test a name, an expected result and an owner. Record which Entra ID app registration, redirect settings, Azure OAuth configuration and Odoo mail server entries are in use, so that a failed test can be traced to a specific setting. Confirm with your Microsoft 365 administrator which mailboxes, licenses and tenant policies the pilot will depend on before the first test runs.
Start the mail tests with outbound and inbound traffic in both directions. Send from Odoo to an external address and to a test mailbox, with attachments of different sizes and file types. Reply from the mailbox back into Odoo so that incoming routing and threading are exercised as well. Open the received headers and check the Authentication-Results field for SPF, DKIM and DMARC outcomes, and confirm that the From domain aligns with the domain Odoo sends from. Ask your mail security team which DNS records and tenant policies they expect, because a message can be delivered and still fail alignment checks.
Test calendar synchronization in both directions with recurring events. Create a series in Odoo, confirm that Outlook shows the same pattern, then edit a single occurrence and then the whole series from each side. Repeat the test with exceptions, deleted occurrences, changed attendees, all-day events and a time zone different from the server's. Attendees outside your tenant should be included. Where the same event is edited on both sides before a sync runs, the outcome is a design decision, so write down which side wins and confirm the actual behavior against the version you deploy.
Test the Outlook plugin from a clean Outlook profile, not only from a profile that has been in use for months. A new profile shows the first-run experience, the consent prompts and the permissions a user actually sees, and it exposes leftover settings that an established profile hides. Then test sign-in with two accounts: one user who has no Odoo account, and one who already has an account, including a case where the Microsoft account and the existing Odoo login share an email address. Check the Odoo documentation for your version on how accounts are created at first Microsoft sign-in, and confirm that behavior in your own environment.
Run the full suite on a copy of the production database made with Odoo's database duplication and neutralization feature. Neutralization disables several production features, including outgoing mail servers and scheduled actions, so test traffic does not reach real customers. Confirm the list of what is neutralized for your Odoo version, then verify that a test email is blocked or redirected before you rely on the copy. Record every result with the date, Odoo version, configuration state, tester, outcome and evidence, so the same suite can be repeated after each upgrade and the results compared.
Securing the Microsoft 365 connection in Odoo
Microsoft 365 connections in Odoo depend on Entra ID app registrations, client secrets and the accounts that consent to their permissions, and Odoo's own sign-in and support settings. The six controls below cover those parts in turn. Confirm each one against the Odoo version you run and your tenant policy before you rely on it.
Least-privilege permissions per registration
Create a separate Entra ID app registration for each Odoo connection, such as outgoing mail, incoming mail, calendar or Microsoft sign-in, and request only the Microsoft Graph permissions that connection needs. A mail sender does not need calendar scopes, and a sign-in registration does not need mailbox access. Review the granted permissions after every configuration change, and check the Odoo documentation for your version to see which scopes each feature requests.
Client secrets in a managed vault
Keep each client secret in your organization's managed vault and enter it into Odoo only when the connection is configured. Entra ID client secrets expire, and an expired secret can stop mail or calendar sync, so record every expiry date in the vault and in your team calendar, and schedule renewal well before it falls due. Ask your partner where Odoo stores the value in the database and which database users can read it.
Administering and logging connection settings
Limit who can open and change Microsoft connection settings in Odoo to a named group of administrators, and confirm which technical menus your version restricts to that group. Consent grants and configuration changes should leave a record: who consented to which permissions, when a secret or tenant identifier changed, and who edited a connector. Ask which Odoo and Entra ID audit logs capture each event and where your team will export them.
MFA and conditional access for consenting accounts
Any account that grants consent to Microsoft 365 permissions should sign in with multi-factor authentication. Entra ID conditional access policies can require MFA, compliant devices or trusted locations for those accounts, and admin consent should go only to people who need it. For Odoo logins, check whether two-factor authentication is documented for your version, and enable it for administrators first. Test each policy in a non-production tenant before you apply it to production.
Restricting sign-in to the intended tenant
Set the tenant identifier in the Microsoft sign-in configuration to your own directory, and avoid multi-tenant endpoints unless you have a documented business need for them. During testing, sign in with an account from a different directory and confirm that Odoo refuses it. Confirm with the Microsoft Azure OAuth documentation for your Odoo version how the tenant is validated, and record the result in your configuration notes.
Keeping the server within the support window
Odoo's standard support covers the first three years after a major release, including security updates and bug fixes, and security patches are provided only during that window. Odoo 19.0 is in standard support until September 2028, and Odoo 17.0 standard support ended in September 2026. Plan upgrades before the window closes, and confirm your version's support dates on Odoo's support page before you connect Microsoft 365.
Common Microsoft 365 integration failures and their causes
This table lists the failures most often seen when Odoo connects to Microsoft 365, with the likely cause, how to confirm it in the Entra portal, Odoo logs or a network trace, and the fix. Start from the symptom you see and verify the cause before changing any configuration. Most of these failures trace back to the app registration, tenant consent or the network path, so check those three first.
| Symptom | Likely cause | How to verify | Fix |
|---|---|---|---|
| Redirect URI mismatch after a domain change | The app registration still lists the old Odoo domain as its redirect URI. | Compare the redirect URI in the Entra app registration under Authentication with the callback URL Odoo shows in its setup. | Add the new callback URL to the web redirect URIs and keep the old one until the cutover completes. |
| Sign-in or mail fails with a consent required error | Permissions were added to the app registration, but a tenant administrator never granted admin consent. | Check the API permissions page for a Not granted status, and read the error in the Entra sign-in logs. | Have a Global Administrator grant admin consent for the tenant, then retest the sign-in. |
| Token requests fail after months of working | The client secret reached its expiry date and no replacement was stored in Odoo. | Check the expiry date under Certificates and secrets, and look for authentication failures in the Odoo server log. | Create a new secret, store it in the Odoo configuration, and set a calendar reminder before the next expiry. |
| Outgoing mail rejected by the server | The sending mailbox lacks SMTP client authentication, or the From address is not an accepted domain in the tenant. | Read the SMTP response codes in the Odoo mail log and run a message trace in the Exchange admin center. | Enable SMTP AUTH on the sending mailbox if policy allows, and use an accepted domain as the sender. Confirm current Microsoft requirements. |
| Calendar events duplicated or not updated | Two sync paths write the same event, or the calendar has no single owner in Odoo and Outlook. | Compare the event IDs in the Odoo calendar with those in Outlook, and review the Odoo scheduled action log for the sync. | Assign one owner per calendar, remove duplicate series, and rerun the sync after confirming the account links to the right user. |
| Outlook plugin fails to load | The add-in manifest points to an Odoo URL the user's client cannot reach, such as an internal hostname or an incomplete certificate chain. | Test the URL from outside the internal network, check the TLS chain, and review the add-in console errors in the browser. | Publish a reachable HTTPS URL with a complete certificate chain, update the manifest, and redeploy it to users. |
| Microsoft sign-in creates duplicate Odoo users | Email case differs or a secondary alias is used, so Odoo treats the same person as a new login. | Search the Odoo users list in lowercase, and compare the email or UPN claim in the sign-in token with the stored login. | Normalize email addresses to lowercase, match on the identifier your setup relies on, and archive duplicates after review. |
| Self-hosted server cannot reach Microsoft services | Outbound firewall rules block the Microsoft sign-in endpoints, Graph endpoints or the SMTP submission port. | Run curl or telnet from the Odoo host to each endpoint, then check firewall deny logs and Odoo timeout errors. | Allow outbound HTTPS and the SMTP submission port from the Odoo host only, using the endpoint list Microsoft currently publishes. |
Questions buyers ask before hiring help with Microsoft 365 in Odoo
How much does Microsoft 365 integration with Odoo cost?
The cost depends on the written scope, so there is no standard figure to quote here. The main drivers are the number of features in scope (outgoing and incoming mail, Outlook Calendar synchronization, the Outlook mail plugin and Microsoft sign-in), the number of tenants and mailboxes, the Odoo edition and hosting constraints, whether a test environment exists, and the security review your organization requires. Each feature adds Entra ID app registration, configuration and testing work. Ask for a quote that lists each feature separately, states which items are one-time (build, configuration, documentation, knowledge transfer) and which recur (support, renewals of licenses or subscriptions you hold, and updates after Odoo releases). DeployOpen works from a written scope agreed before work starts, and a quote follows from that scope.
How long does a Microsoft 365 integration project take in Odoo?
Duration follows the same drivers as cost: how many features are in scope, how many tenants and mailboxes are involved, and how quickly a test environment and approvals can be arranged. A single feature in one tenant is usually much shorter than a multi-tenant rollout with a formal security review, but the timeline should come from the written scope rather than a general estimate. Ask for milestones that separate discovery, Entra ID app registration, Odoo configuration, testing in a non-production database, cutover and handover. Also confirm which dates depend on your administrators being available to approve app consent and change requests.
What does DeployOpen need from our team to start?
DeployOpen needs administrative access to the Microsoft 365 tenant, specifically rights to register applications in Entra ID and grant the permissions each feature requires. It also needs test accounts and mailboxes that can be used without affecting real customer or employee mail, plus a non-production Odoo database where configuration can be validated first. You should also name a business owner who can approve the scope, a security contact for the review, and the people who will use the integration. Confirm these inputs in the written scope so that access requests and approvals are not discovered mid-project.
Can our internal team set up the Microsoft 365 integration without a partner?
Yes, provided the team has working knowledge of both Entra ID and Odoo administration and follows the documentation for the Odoo version you run. The work involves app registrations, redirect URIs, API permissions, consent, and the Odoo settings that store and use those credentials, so mistakes often come from small configuration gaps rather than missing features. A partner adds value when the scope spans several tenants, when a formal security review must be evidenced, or when the team lacks time to test and document the result. Whichever route you choose, run the work in a test database first and record each registration and setting so it can be audited and repeated.
Which Odoo edition and hosting type do we need for this integration?
Confirm this before scoping, because edition and hosting limit what you can build. According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Odoo Online plans are limited to Odoo Online hosting. If you run Community, the integration must use features available in that edition and you will rely on community-maintained modules for anything else. Check the current plan details on Odoo's pricing page and confirm them with Odoo before committing to a design.
What happens to the Microsoft 365 integration when we upgrade Odoo?
Plan for it from the start. Odoo releases new versions on a schedule, and the Microsoft connection can depend on module code and settings that change between versions. Confirm your version's support window on Odoo's standard and extended support documentation, because security patches are only provided during standard support. Test the integration on an upgraded test database before the production upgrade, following Odoo's upgrade documentation. Keep the Entra ID app registration details and the Odoo configuration written down so the upgrade test can be checked against them.
Does the security review need to be completed before the integration goes live?
In most regulated environments, yes, and the review should be scoped with the rest of the project. The review usually covers the app registration permissions granted in Entra ID, how credentials and secrets are stored and rotated, which mailboxes and calendars the integration can reach, and how sign-in is configured. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies perform those assessments, so ask your auditor which evidence they will need before the build starts.
How DeployOpen scopes, delivers and supports the Microsoft 365 integration
DeployOpen plans, implements, integrates and documents Odoo and Microsoft 365 connections inside your own infrastructure, from the first mapping of mail, calendar and sign-in flows to handover. Engagements are fixed-scope, with deliverables agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- The written scope lists which Microsoft 365 features are in use: mail, Calendar, the Outlook plugin or sign-in.
- Entra ID app registrations, redirect URIs, permissions and tenant assumptions are mapped before any build work starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
How we build
- Outgoing and incoming mail use Azure OAuth, with Entra ID app and mailbox permissions scoped to your tenant.
- Calendar synchronization, the Outlook mail plugin and Microsoft sign-in are configured and tested as separate components.
- Test mailboxes and test accounts verify each flow in a non-production environment before production cutover.
How we hand over
- Handover includes the app registration settings, configuration records and the steps for rotating client secrets or certificates.
- Runbooks cover failed mail delivery, expired credentials, consent changes and calendar sync errors, written for your administrators.
- Documentation is written for your team so administrators can operate the integration after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover Odoo upgrades and Microsoft 365 changes, such as updated permissions or tenant policy changes.
- Changes to Microsoft 365 tenant policy or Odoo versions are reviewed against the integration before they reach production.
