--- title: 'Microsoft 365 integration' summary: 'Connects your PBX to Microsoft 365 to provision users from Entra ID and sync Outlook contacts both ways.' section: features tags: - telephony - integrations - microsoft updated: '2026-09-09' --- > The Microsoft 365 integration connects your PBX to Microsoft Entra ID and Microsoft Graph so user accounts and contacts stay aligned between Cockpit and Microsoft. ## Overview Microsoft 365 is one of the integration types you configure under [Integrations](integrations.md). It uses your Microsoft tenant to read directory users and to read and write each user's Outlook contacts through Microsoft Graph. Each sync behavior has its own toggle, so you can enable only the parts you need. ## What it does Before any sync runs, the integration needs admin consent in your Microsoft Entra tenant. Until consent is granted, the user sync and the contact push stay off even when the integration is active and the toggles are on. Consent is granted once per tenant against the Voxbi application registration. The integration authenticates to Microsoft Graph using the application client credentials flow, scoped to your tenant. Access tokens are obtained and cached automatically, so you do not enter or manage a token yourself. The toggles, all on the Microsoft 365 tab, work as follows. - **Fetch Microsoft users to Cockpit** (`microsoft_users_sync`) pulls users one way, from Microsoft Entra into Cockpit. Cockpit reads each directory user and provisions a matching Cockpit user account, carrying over first name, last name, email, active state, business phone as the extension, mobile number, office, and city. This direction requires admin consent. See [Users](users.md) for the accounts that result. - **Push contacts to Microsoft** (`microsoft_contacts_sync`) pushes contacts one way, from Cockpit out to Microsoft. For each enabled Cockpit user it maintains two contact folders in that user's Outlook account, one for global contacts and one for that user's personal contacts, and creates, updates, or removes Microsoft contacts to match what is in Cockpit. This direction also requires admin consent. See [Contacts](contacts.md) for the source records. - **Fetch contacts from Microsoft** (`microsoft_user_contact_sync`) pulls contacts the other way, reading a user's Microsoft contacts from the same two folders so Cockpit can show them. This is a read-only view of what already exists on the Microsoft side. - **Push notifications to Teams** (`microsoft_push_notifications_to_teams`) delivers call notifications to the called employee's Microsoft Teams activity feed. Your PBX marks a notification for Teams, and one marked that way goes to Teams only, not to the employee's Voxbi apps as well. Delivery also needs the Voxbi Teams app installed for that employee, and depending on how your server is set up it may need a separate authorization, described under [Authorizing Teams notifications](#authorizing-teams-notifications). Turning the switch off stops it immediately. > [!NOTE] > This is not the same as the [Microsoft Teams integration](microsoft_teams_integration.md), which is Direct Routing through a Session Border Controller so Teams users can place calls through the PBX. That one is a separate integration with its own entry. This switch only sends notifications into the Teams activity feed. The two contact directions are independent of each other but both operate on the same per-user global and personal folders, so the push direction is what populates those folders in the first place. > [!NOTE] > The push direction matches existing Microsoft contacts by email, then phone, then name before creating new ones, which avoids duplicating contacts that are already present. When the same people are synced across more than one Microsoft 365 integration, the toggles can still produce duplicates. When a Cockpit user is disabled, the integration removes that user's contacts from their managed Microsoft folders so stale entries do not linger. ## Operations ### Authorizing Teams notifications Whether Teams notifications need their own authorization depends on how your server is configured, so go by what the Microsoft 365 tab shows you. - **If the tab has a separate Teams notifications section with its own Authorize Teams notifications button**, notifications are sent by a different Microsoft application than the syncs, and a Microsoft administrator has to authorize that one too. Until they do, the switch can be on while nothing is delivered. - **If there is only the switch and no second button**, the same application sends everything and the authorization described above already covers Teams notifications. Where the second button exists it also serves as a re-authorization. A permission added to the Voxbi application is not granted in your organization until an administrator consents again, so if notifications stop arriving after an update, clicking it again is the first thing to try. ### When notifications do not arrive Where the separate Teams notifications section is shown, the last refusal Microsoft gave appears there in a red panel with the time it happened. Three causes account for nearly all of them. - **Authorization is missing or was withdrawn.** Use the Authorize Teams notifications button again. - **The Voxbi app is not installed for that employee in Teams.** Microsoft cannot deliver to somebody who does not have the app. The employee can add it themselves, or an administrator can install it for everyone at once with a Teams app setup policy in the Teams admin center. - **Something is wrong on the Voxbi side.** The panel says so explicitly. Report it rather than changing settings. A notification is only ever sent while a call is ringing, so a quiet panel with no recent calls does not confirm the setup works. Place a test call to the employee to check it end to end. ## See also - [Integrations](integrations.md) - the integration entity and its full field reference. - [Users](users.md) - provisioned from Microsoft Entra. - [Contacts](contacts.md) - the contact sync target.