For most teams, connecting Outlook calendars to HubSpot is a per-user task: each rep connects their own Office 365 calendar to the meetings tool, and HubSpot's calendar sync keeps meetings and availability aligned with the CRM. What HubSpot does not do natively is manage a whole team's calendars through one connection or read shared calendars — sync works with each user's primary calendar only. When you need centralized or shared-calendar behavior (scheduling coordinators booking into reps' calendars, for example), the path is a custom Microsoft Entra app using Microsoft Graph permissions like Calendars.ReadWrite.Shared with admin consent — and that pattern needs deliberate offboarding handling, because the connection breaks when the connected user leaves.
HubSpot offers two related but distinct connections, and both are per-user:
Two constraints matter for team design. First, both connections sync with the user's primary or default calendar only — a shared team calendar or a colleague's calendar you have access to will not sync. Second, there is no admin console where one person connects calendars on behalf of the whole team; each user authenticates their own account.
When native connections don't fit — the classic case is a scheduling team that books appointments into many reps' calendars, or meeting invitations that must come from a shared mailbox — organizations build on Microsoft's identity layer instead. That means registering an application in Microsoft Entra ID (formerly Azure AD) and granting it Microsoft Graph calendar permissions with admin consent.
The permissions that typically appear in this pattern:
| Graph permission | What it allows | When you need it |
|---|---|---|
| Calendars.ReadWrite | Read and write the signed-in user's calendars | Basic booking into a user's own calendar |
| Calendars.ReadWrite.Shared | Read and write calendars shared with or delegated to the user | Coordinators booking into reps' calendars; shared calendars |
| User.Read | Sign in and read the user's basic profile | Nearly always — baseline identity permission |
| offline_access | Refresh tokens so the app keeps working without re-login | Any integration that runs unattended |
A tenant admin grants these via admin consent, which is what turns a per-user OAuth flow into an organization-sanctioned integration. If your IT team can't find the client secret or certificate for an existing app, they're in the app's Certificates & secrets blade in the Entra portal — a detail that stalls many of these projects for a week while someone hunts for the right screen.
Start with the native path and escalate only if it genuinely can't express your workflow:
This is the failure mode that brings these setups down. If the integration authenticates as a specific employee — or a meetings workflow depends on that person's calendar connection — their departure, email change, or license removal silently breaks scheduling. Meetings stop writing to calendars, availability goes stale, and nobody notices until a prospect complains.
The mitigations are boring but decisive: connect integrations through a service account or group where your tenant allows it, keep the dedicated security group pattern so access survives individuals, and put "transfer the calendar integration" on the offboarding checklist next to "disable the login." A quarterly check that the connection is still alive beats discovering the break in a pipeline review.
Vantage Point implements HubSpot for teams whose scheduling reality is messier than the default setup — coordinators booking for field reps, shared inboxes, rotating on-call calendars. We design the calendar and meeting architecture, work with your IT team on the Microsoft Entra side when a custom integration is warranted, and document the dependencies so the next personnel change is a non-event. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
If you're mid-implementation or untangling a fragile setup, our HubSpot implementation team builds these patterns in from the start rather than retrofitting them after the first breakage.
We'll map your scheduling workflow, choose the simplest connection pattern that fits, and make sure it keeps working when people move on.
Not natively. HubSpot's calendar sync and meetings tool connect to each user's primary or default calendar only. Shared or delegated calendars require a custom integration through Microsoft Entra ID with Microsoft Graph shared-calendar permissions (such as Calendars.ReadWrite.Shared) granted via admin consent.
Yes, for the native tools. HubSpot has no admin-level bulk connection: each user authenticates their own Office 365 or Google account for the meetings tool and calendar sync. For teams that need central management, the alternative is a custom Entra app — which trades per-user setup for integration development and maintenance.
It depends on the workflow. Booking into a user's own calendar needs Calendars.ReadWrite; touching shared or delegated calendars needs Calendars.ReadWrite.Shared; User.Read is the baseline identity permission; and offline_access provides refresh tokens so the integration keeps working without repeated logins. Grant the minimum set, with admin consent, and document what was granted.
Anything authenticated as that person stops working: their meetings links lose availability, calendar sync halts, and coordinator workflows that ran through their account fail. Mitigate with service accounts or mail-enabled security groups where possible, and add the integration handoff to your offboarding checklist.
The meetings tool and calendar sync are tied to HubSpot users, so the person whose calendar connects needs a HubSpot user account; whether that requires a paid seat depends on your HubSpot subscription and what else that user does. A custom Entra/Graph integration, by contrast, authenticates to Microsoft — not per HubSpot user — which is one reason coordinator-heavy teams choose it.
Client secrets live in the app registration's Certificates & secrets blade in the Microsoft Entra admin center — and existing secret values can't be viewed again after creation, only new ones generated. If no one recorded the secret, the fix is to create a new client secret, update the integration, and store the value in your password vault this time.