How Mattermost and Microsoft Teams integration works for mixed-tool teams
If your team runs Mattermost but still receives work in Microsoft Teams, the documented method is the Mattermost Microsoft Teams integration, which forwards real-time chat notifications from Teams into Mattermost. Setup runs through an Azure app registration that Mattermost uses to read Teams chat activity on behalf of your users. Treat it as a bridge for notifications, so people see new Teams messages in Mattermost without switching apps, not as a way to move your Teams history.
The integration does not migrate messages. It delivers new chat notifications as they arrive, and it does not copy existing Teams conversations, channels or their history into Mattermost. If you need past Teams content in Mattermost, that is a separate migration project with its own scope, and the integration cannot substitute for it. Confirm this boundary with stakeholders early, because teams often assume a notification bridge also carries history.
Plan requirement comes first. The Mattermost Microsoft Teams integration is available on Entry, Enterprise and Enterprise Advanced plans but not on Professional. If your organization is on Professional, confirm the plan change with Mattermost before you design around this integration, since the answer changes the whole approach. Ask your Mattermost account contact to confirm which plan your license covers and whether any terms apply to your deployment.
Setup has a few decisions you should make in advance. The Azure app registration needs a redirect URI built from your Mattermost site URL, so the URL you set in MM_SITE_URL must be final and reachable before you register the app. The Microsoft Graph delegated permissions documented for the integration include Chat.Read, ChatMessage.Read, Files.Read.All and offline_access. Have your Entra ID administrator review whether these permissions meet your security policy, and confirm consent requirements with your tenant administrator before the build starts.
Operational risk sits mostly in access and ownership. Notifications reach users only for the Teams accounts the integration is authorized to read, so decide which users are in scope and who manages the connection when someone leaves. Confirm with your identity team how the app registration, client secret or certificate and its expiry will be rotated, since a lapsed credential stops notifications silently. Verify delivery with a test account before rollout, and document who owns the app registration and the Mattermost plugin configuration.
What you need before connecting Teams to Mattermost
The Teams integration depends on four things lining up before any app is registered: the Mattermost plan, a public HTTPS address for the server, Entra ID rights, and the Microsoft 365 tenant that holds the chats. Confirm each one first, because a gap in any of them usually surfaces only partway through setup.
Mattermost plan that includes the integration
The Microsoft Teams integration is listed for Entry, Enterprise and Enterprise Advanced plans but not Professional, so a Professional subscription will not support it. Confirm your plan and seat licenses with your Mattermost account contact before scheduling work. Plan names and inclusions can change, so check the current pricing page and the integration documentation against your contract.
Reachable MM_SITE_URL over HTTPS
The setup derives the OAuth redirect from MM_SITE_URL, so this value must match the public address users and Microsoft will reach, including the scheme. The site must present a valid HTTPS certificate that Microsoft's sign-in flow can reach from the internet. Internal-only hostnames or self-signed certificates will block the consent step, so confirm DNS, certificate chain and firewall rules with your network team first.
Entra ID rights to register and consent
Someone with rights to register an application in Microsoft Entra ID and to grant admin consent for Microsoft Graph delegated permissions must perform the setup. The permissions include chat and file read scopes plus offline access, which are sensitive for many tenants. Confirm with your identity team whether they hold these roles or whether a change request and approval workflow applies before the work starts.
Microsoft 365 tenant holding the chats
The integration reads chats from the Microsoft 365 tenant where the Teams conversations live, so the app must be registered in that same tenant. If your organization has several tenants, or chats sit with a partner or subsidiary tenant, identify the correct one before registering anything. Mismatched tenants are a common reason the sign-in or permission grant fails.
Scope of delegated Graph access
The delegated permissions, including Chat.Read, ChatMessage.Read and Files.Read.All, let the integration read chat content and shared files on behalf of signed-in users. Your security and privacy owners should agree on which users and chats are in scope and how the data is retained in Mattermost before consent is granted. Review the permission list in the vendor documentation to confirm it has not changed.
Confirm server and plugin versions
Confirm the current Mattermost server version and the Teams plugin version running in your environment against the vendor documentation before you plan the change. The server release schedule and the plugin's compatibility notes both affect whether the setup steps you read apply to your build. Record both versions in the change request so that the team can verify them again during testing and upgrades.
Configuration sequence for the Teams sync plugin
This sequence takes a self-hosted Mattermost server from a plan check to a verified feed of Microsoft Teams chat notifications. It covers the Entra ID app registration, the redirect URI, the Microsoft Graph delegated permissions, the Mattermost plugin settings and an end-to-end test. Run it first in a non-production tenant and server where possible.
Confirm plan and plugin availability
The Mattermost subscription owner and a Microsoft Entra ID administrator confirm the starting point before anything is registered. The Teams sync plugin is listed for Entry, Enterprise and Enterprise Advanced plans, so a Professional subscription would need a plan change before setup. Confirm the Mattermost server is reachable at its public site URL, because the Azure redirect depends on that value. Confirm the plugin is offered on your server version. Done when the plan level, server version and site URL are recorded in the change request.
Register the Azure app in Entra ID
An Entra ID administrator registers a new application in the Azure portal for the sync. Record the application (client) ID and the directory (tenant) ID, and store them in your secrets vault. Confirm with the plugin documentation for your version whether a client secret is required. If it is, note its expiry date and schedule the rotation, and name the person who owns the registration. Done when the app registration exists, its identifiers are stored and any secret has a recorded expiry date.
Set the redirect URI to MM_SITE_URL
In the app registration's authentication settings, add a web redirect URI made from your MM_SITE_URL value followed by /plugins/com.mattermost.msteams-sync/oauth-redirect. The scheme, host and path must match exactly, and the same site URL must appear in the Mattermost System Console. A mismatch is the most common reason the sign-in step fails later. Done when the redirect URI is saved under the web platform and matches the Site URL shown in Mattermost.
Add Graph delegated permissions
Add the Microsoft Graph delegated permissions Chat.Read, ChatMessage.Read, Files.Read.All and offline_access to the app. Delegated permissions act as the signed-in user, so the person who connects the account must be able to see the chats they expect to forward. Ask your tenant administrator whether admin consent is required under your tenant policy and grant it if so. Files.Read.All reads a wide range of files, so record the business reason in the change request. Done when all four permissions are listed with the consent status your policy requires.
Enable the plugin in Mattermost
A Mattermost system administrator enables the Microsoft Teams sync plugin in the System Console and enters the client ID, tenant ID and any secret the plugin requests, using the values from the Azure registration. Confirm the setting names in your server version, since they can change between releases. Restrict who can view plugin settings, because the secret should not be readable by general administrators. Done when the plugin shows as enabled, the settings save without error and the server log shows no startup errors for the plugin.
Connect the Microsoft account
A user with the right Teams access opens the connect option in the plugin settings, signs in with their Microsoft account and approves the requested permissions. The connection belongs to that user, so decide in advance which account owns the integration and who will reconnect it if that person leaves or changes role. Done when the plugin shows the account as connected and the connected user is recorded in your integration register.
Test a Teams notification
From a second Teams account, send a chat message to the connected user, then confirm it arrives in Mattermost with the sender and text intact. Repeat the test with a file attachment, since file handling depends on the Files permission. If nothing arrives, check the Mattermost server log for plugin errors and recheck the redirect URI and permissions. Done when the test message and attachment both appear in Mattermost, and the result is recorded with the Mattermost server version and plugin version.
How Mattermost stores and forwards Teams notifications
The Mattermost Microsoft Teams integration works through delegated access. Each person who connects their Teams account consents to Microsoft Graph permissions, and the integration then acts as that user when it reads their chat activity. The sequence starts in Mattermost, where the user begins the connection. The user signs in to Microsoft, approves the requested permissions, and Microsoft sends them back to the OAuth redirect on your Mattermost site. From that point, chat notifications from the connected user's Teams conversations are forwarded into Mattermost. The redirect is part of the Azure app registration your administrator creates in Entra ID, so the sign-in path depends on the Mattermost site URL being configured correctly before any user connects.
The permissions are the main design input. The documented delegated scopes are Chat.Read, ChatMessage.Read, Files.Read.All and offline_access. Chat.Read and ChatMessage.Read cover the chat content the integration forwards, Files.Read.All covers files, and offline_access is the scope that lets the connection persist without the user actively signed in. Because the access is delegated, the integration can only reach what the consenting user can already see in Teams. It does not gain access to other people's conversations by being installed. Your team should confirm with Microsoft documentation and your tenant administrator whether any of these scopes require administrator consent in your tenant, and whether your Entra ID policies restrict user consent to apps.
Scope and retention decisions belong to your organization, not to the integration. Before rollout, decide which users are allowed to connect their accounts, whether every connected user must be covered by your acceptable use and monitoring policies, and what happens when someone leaves the company or revokes consent. Revocation in Microsoft, removal of the Mattermost connection and deletion of the Azure app registration are three separate actions, and each should appear in your offboarding runbook. Confirm with Mattermost documentation where the OAuth tokens are held on your server, how they are protected, and how an administrator can disconnect a user without that user's cooperation.
Forwarded notifications become content in your Mattermost deployment, so their retention, access and export follow your Mattermost configuration. They are not automatically governed by the retention policies you set in Teams. Teams retention and legal hold settings may not apply to the copies in Mattermost, and Mattermost retention settings may not match your Teams policy. Ask your compliance lead to map the two systems side by side, and confirm with Mattermost which content types the integration stores and for how long, before the integration reaches users who handle regulated or records-bound conversations. Plan to document the answer as part of your data inventory, and review it again after any Mattermost upgrade that changes plugin behavior.
Which Teams objects map to which Mattermost objects
This table pairs each Microsoft Teams object in the integration with the Mattermost object it corresponds to during setup and sync. Read each row as either a setup input or a data path, and treat the last rows as the scope limit. Confirm the exact field names, sync targets and permission behavior in the plugin documentation before you plan the build.
| Object | Microsoft Teams side | Mattermost side |
|---|---|---|
| Chat notifications | Chat messages the signed-in user can read, delivered through Graph delegated permissions | Forwarded into Mattermost as posts by the Teams sync plugin; confirm target channels in the plugin docs |
| Signed-in user identity | The Microsoft Entra ID user who signs in and grants delegated consent | The Mattermost user account connected to that identity; confirm how accounts are matched |
| Entra ID tenant | Directory that owns the users and the app registration | No separate Mattermost object; the tenant is entered in plugin configuration, so confirm field names |
| App registration | Azure app with client credentials and Microsoft Graph delegated permissions | Plugin settings that store the app's client identifiers and OAuth values; confirm the supported secret type |
| Redirect URI | Registered in the app as the site URL plus /plugins/com.mattermost.msteams-sync/oauth-redirect | Built from the Mattermost site URL, so the SiteURL setting must match the registered value exactly |
| Graph permissions | Delegated scopes including Chat.Read, ChatMessage.Read, Files.Read.All and offline_access | Determine what the plugin can read and forward; confirm the full scope list in the plugin docs |
| Not mapped | Team channels, meetings, calendars and file contents beyond what the documented permissions read | No equivalent sync is documented; confirm before promising it to users or stakeholders |
| Plan availability | Integration documented for Entry, Enterprise and Enterprise Advanced plans | Not available on the Professional plan; confirm your plan level before scoping the work |
Securing the Teams and Entra ID connection
The Teams sync connection sits where your Microsoft tenant meets your self-hosted Mattermost server, so a weak app registration or an overly broad consent exposes chat content from both sides. The cards below cover the controls to review before and after setup, and each one points to the Microsoft and Mattermost policies your organization already applies.
Least-privilege review of Graph permissions
The setup documents delegated Microsoft Graph permissions such as Chat.Read, ChatMessage.Read, Files.Read.All and offline_access. Compare each one with the notification scope you actually need, and ask whether file-wide read access is required or whether a narrower option satisfies your use case. Record the justification for each permission in your change record so a later reviewer can see why it was granted.
Admin consent governance in Entra ID
Delegated permissions that require administrator consent should go through your existing Entra ID consent workflow, not a shortcut granted by a single administrator. Confirm who may approve consent for the app, whether user consent is restricted for the tenant, and which approver signs off on the permission set. Keep the approval tied to a named ticket so the decision can be traced.
Protecting the client secret and redirect URI
The Azure app's client secret grants the sync service its identity, so store it in your approved secrets manager, restrict who can read it, and set a rotation date that matches your credential policy. Confirm that the redirect URI registered in Entra ID matches your Mattermost site URL exactly, including scheme and path, and that no extra redirect URIs remain from testing.
HTTPS on the Mattermost site
The OAuth redirect returns the user to your Mattermost site, so that site must serve HTTPS with a certificate your users and Microsoft's sign-in flow trust. Check the TLS configuration against your organization's baseline, confirm that HTTP requests redirect to HTTPS, and make sure the site URL in the Mattermost configuration uses the same hostname registered in Entra ID.
Who may connect accounts
Each Mattermost user who connects a Microsoft account grants the sync access to their own chats. Decide whether every user may connect, or only a defined group, and enforce that choice through your Mattermost roles and onboarding process. Confirm with your privacy and records team whether connected personal chat forwarding is permitted under your acceptable use policy.
Auditing the consent grant
Review the consent grant in Entra ID after setup and on a recurring schedule, including the consenting user, the granted scopes and any changes since approval. Compare the sign-in and audit logs against the expected connection activity, and remove the grant when the integration is retired. Use your existing Microsoft audit retention to keep this evidence available for review.
Which Mattermost plan includes the Teams integration and what drives cost
The Mattermost Microsoft Teams integration is available on Entry, Enterprise and Enterprise Advanced, and it is not available on Professional. Plan selection is therefore the first decision in this project, before any Azure work begins. The Mattermost pricing page lists Professional, Enterprise and Enterprise Advanced by name, so confirm with Mattermost sales which current plan matches Entry and that it includes the Teams sync at the time you buy. Mattermost sells its plans as prepaid annual subscriptions based on seat licenses, and its pricing page lists no public prices and directs buyers to contact sales. Treat the subscription as a recurring annual cost set by your seat count and plan level, and get the figure in writing before you build a budget.
The subscription is only one cost component. Internal or partner effort to register the Azure app, set the redirect URI for your MM_SITE_URL, grant the Microsoft Graph delegated permissions (Chat.Read, ChatMessage.Read, Files.Read.All and offline_access), and test the sync with a pilot group is usually a one-time cost. Its size depends on whether your identity or cloud team has done app registrations before, how many Teams tenants are in scope, and how many test accounts you need to prove that chat notifications arrive in the right Mattermost channels. Ask any partner to state which of these tasks are inside the fixed scope and which would be billed as extra work if a tenant setup takes longer than planned.
Microsoft tenant governance is a cost that teams often underestimate. Someone must own the app registration, approve admin consent for the delegated permissions, and rotate its client secret or certificate on a schedule. Files.Read.All is broad, so your Microsoft 365 administrators should decide whether that scope is acceptable for your data classification and whether conditional access or audit logging must apply to the app. These decisions recur: each credential rotation, consent change and tenant review takes staff time that should appear in your internal estimate. Name the owner of these tasks before the pilot starts, not after the first audit question.
Ongoing review is the recurring engineering cost. Mattermost publishes server binaries on the 16th of each month, and Extended Support Release v11.7 was released on 2026-05-15 with support ending 2027-05-15. Each server upgrade should be checked against the Teams sync in a staging environment before production. When you request a quote, ask for the plan name, seat count and term; what the subscription includes; whether Teams sync is confirmed on your plan; who performs app registration; the pilot test scope; the fee basis for post-release review (fixed, per release or retainer); and the renewal price terms. A written scope is what makes these figures comparable.
Common Teams sync failures and how to fix them
This table lists the failures that most often stop Teams chat notifications from reaching Mattermost, with the likely cause, the fix and where to check it. Work through the Entra ID app registration first, then the Mattermost system console, because most failures trace back to the redirect URI, permissions or consent. Confirm menu labels and steps against the setup guide for your Mattermost version before changing settings.
| Failure | Likely cause | Fix | Verify in |
|---|---|---|---|
| Redirect URI mismatch | The redirect URI in the Azure app does not exactly match the Mattermost site URL | Add https://MM_SITE_URL/plugins/com.mattermost.msteams-sync/oauth-redirect using the same scheme, host and path | Entra ID app Authentication page; system console Site URL |
| Missing Graph permissions | Required delegated permissions were never added to the app registration | Add Chat.Read, ChatMessage.Read, Files.Read.All and offline_access as delegated Microsoft Graph permissions | Entra ID app API permissions list |
| Admin consent not granted | Permissions were added, but a tenant administrator has not approved them for the organization | Have a tenant administrator grant admin consent and confirm each permission shows as granted | Entra ID app API permissions consent status |
| Plugin unavailable on plan | Teams sync is listed for Entry, Enterprise and Enterprise Advanced plans, not Professional | Confirm the license includes the plugin before setup, or upgrade the plan first | System console license details; confirm plan with Mattermost sales |
| Expired or revoked tokens | The consenting user left the organization, or the account was disabled, so token refresh fails | Reconnect the sync with a current user who has Teams access, then confirm chats forward again | Entra ID user sign-in status; Teams sync plugin settings in the system console |
| Notifications not arriving | The plugin is disabled, or the connected Teams user is not the person whose chats you expect | Confirm the plugin is enabled and running, then send a test chat message from the connected Teams user | System console plugin management; test message in Teams |
Questions buyers ask before connecting Teams to Mattermost
How much does it cost to connect Microsoft Teams to Mattermost?
Cost has three parts: the Mattermost subscription, the Microsoft work in your tenant, and the implementation labor. Mattermost sells Professional, Enterprise and Enterprise Advanced as prepaid annual subscriptions priced by seat licenses, and its pricing page lists no public prices, so ask Mattermost sales for current figures. The Teams integration is available on Entry, Enterprise and Enterprise Advanced but not Professional, so your plan decides whether the integration is possible at all. Implementation effort depends on the Entra ID app registration, Microsoft Graph permission approval, Mattermost configuration, and a pilot with a small group of Teams users. A DeployOpen quote follows a written scope. Ask for one-time items (setup, testing, documentation) listed separately from recurring items (subscription renewal, and any support retainer you choose). Request every assumption in writing, including the number of Teams users, chats and channels in scope.
How long does a Teams to Mattermost integration take to set up?
No duration applies to every environment, and the timeline usually depends on approvals as much as on configuration. The setup registers an application in Microsoft Entra ID, sets a redirect URI built from your Mattermost site URL, and requests Microsoft Graph delegated permissions that include Chat.Read, ChatMessage.Read, Files.Read.All and offline_access. Someone with the right authority in your tenant must review and consent to those permissions, and that step can take longer than the technical work. The Mattermost server also needs a change window if it runs in production. Ask DeployOpen for a schedule as part of the written scope, and confirm with Microsoft which consent process your tenant policy requires before you commit to dates.
What does our team need to provide for the Teams integration?
You need a Mattermost server you control, reachable at a stable site URL, because the Azure redirect URI is built from that address. Changing the URL later means updating the app registration. You also need access to a Microsoft Entra ID tenant with rights to register an application and to approve Microsoft Graph permissions, plus a named Teams user whose chats will be forwarded. Plan a test tenant or test users so the pilot does not touch production conversations. Decide which Mattermost channels will receive notifications and who owns them. Confirm your Mattermost plan and server version before the build starts, and confirm with Microsoft which consent and app governance settings apply to your tenant.
Can our own admins set up the Teams integration without a partner?
Your admins may be able to do it themselves if they have the access the setup requires and have time to work through it carefully. The work covers an Entra ID app registration, Graph permission consent, Mattermost plugin configuration, and testing that forwarded notifications arrive in the right channels. Teams that bring in a partner usually do so because no one has done an app registration with delegated permissions before, consent policies block the first attempt, or the change needs documented evidence for internal audit. DeployOpen implements self-hosted platforms inside your own cloud accounts and data centers, and documents the configuration so your team can run it afterward. Start with the Mattermost integration guide and a pilot, then decide which steps your staff will own.
Does a Mattermost Professional plan include the Microsoft Teams integration?
No. The Mattermost Teams integration is available on Entry, Enterprise and Enterprise Advanced plans, but it is not included in Professional. Professional does include SSO (SAML, OIDC, OAuth) and AD/LDAP user sync according to the Mattermost pricing page, but those features do not enable Teams forwarding. If you are on Professional and need the integration, you will need to discuss a plan change with Mattermost. Confirm with Mattermost sales whether the plan terms or add-ons have changed before you buy, and check the plan shown on your current subscription. Ask DeployOpen to reflect the plan decision in the written scope so the build does not begin on a tier that cannot run the integration.
What happens to the integration when the connected user leaves?
The integration uses delegated permissions, so it acts through a specific Microsoft account and can only forward what that account is allowed to read. If that person leaves the organization, is disabled, or loses access to the relevant chats, forwarding is likely to stop or fail until someone re-establishes the connection. Plan ownership before the build: decide which account is connected, where it is documented, who approves a change, and how a reconnect is performed. Where your Microsoft policy allows, use a dedicated account rather than an individual's mailbox. Confirm with Mattermost how the plugin reacts when the account is removed, and confirm with Microsoft how token refresh and offline_access behave under your tenant policies.
Does the Teams integration migrate existing Microsoft Teams chat history?
The integration is documented to forward real-time chat notifications from Teams into Mattermost. Do not assume it will bring over past messages, files or conversations. The migration paths Mattermost documents that we reviewed cover Slack, Rocket.Chat and GitLab Omnibus, and the Slack path shows that integrations are not carried across in the export. If you need Teams history in Mattermost, ask Mattermost in writing whether a Teams history import is supported on your plan and version, what format it requires, and how attachments are handled. Also confirm how long Teams retains the data under your Microsoft retention policies, so you can decide what to keep in Teams and what to move.
Where to confirm the current setup steps
Treat the Mattermost Microsoft Teams integration documentation as the authority for the exact app registration steps, the redirect URI and the Microsoft Graph permission list. The guide describes the redirect URI as a path under your Mattermost site URL, using the msteams-sync plugin identifier, and it lists delegated permissions such as Chat.Read, ChatMessage.Read, Files.Read.All and offline_access. Copy these values from the guide on the day you make the change, not from an earlier project record or a colleague's notes. Save the page title, the date you read it and the exact values into your change ticket so the reviewer can see what was applied.
Check the guide against the Mattermost server version you actually run before you change anything in production. Mattermost ships a new server version in binary form on the 16th of each month, and Extended Support Releases follow a separate cycle. According to the Mattermost server releases page, v11.11 was released on 2026-09-16 with support ending 2026-12-15, v12.0 was released on 2026-10-16, and v11.7 is an Extended Support Release released on 2026-05-15 with support ending 2027-05-15. Confirm which version the guide describes, whether your server is on a monthly release or an Extended Support Release, and whether a planned upgrade would change the steps.
Confirm the setup with your Microsoft Entra ID administrators against your tenant policy. Delegated permissions that read chats and files usually need an approval decision, and some tenants require administrator consent, restrict who can register applications, or apply conditional access rules that affect how a service sign-in behaves. Ask who grants consent, whether the permission list in the guide is accepted by your security team, and whether any tenant policy blocks the registration. Also confirm your Mattermost plan first, because the Teams integration is listed for Entry, Enterprise and Enterprise Advanced plans but not Professional.
Run the registration and permission steps in a staging Mattermost server and a test tenant before touching production settings. Record each value you set, verify that the redirect URI matches your production site URL exactly, and test a forwarded chat notification end to end. Keep the previous configuration so you can roll back if consent or the sign-in flow fails. If the guide has changed since your last review, repeat these checks rather than assuming the earlier results still apply.
How DeployOpen scopes and delivers the Teams integration
DeployOpen plans the Mattermost and Microsoft Teams integration as part of a self-hosted Mattermost deployment in infrastructure you control. The work starts with a written scope that covers the plan tier, the Entra ID app registration, the Microsoft Graph permissions and the channels that receive forwarded messages. Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
How we scope
- Confirm the Mattermost plan includes the Teams integration before any build, since Mattermost lists the plan levels that include it.
- Record the tenant, the Teams chat sources in scope, and which Mattermost channels receive forwarded messages.
- The written scope lists the Azure app, Graph permissions, redirect URI and any change to your existing Mattermost deployment.
How we build
- Register the Azure app with a redirect URI built from your Mattermost site URL, then configure the sync plugin.
- Grant the delegated Microsoft Graph permissions the integration needs, including Chat.Read, ChatMessage.Read, Files.Read.All and offline_access.
- Test forwarding with a sample chat in a non-production Mattermost before enabling it for the channels in scope.
How we hand over
- Deliver a runbook covering the Azure app settings, permission list, redirect URI, and secrets handling.
- Document which users' chats are forwarded, and who in your organization owns the Azure app and its client secret.
- Walk your administrators through the configuration so your team can review, change and troubleshoot it.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review the Azure app secret and Graph permissions when Microsoft or Mattermost changes its requirements.
- Plan Mattermost server upgrades against the monthly release date and Extended Support Release windows, and retest the integration.
