This guide is for IT and security teams evaluating Bliro's integration with Microsoft Outlook Calendar. It covers the authentication model, the permissions Bliro requests during consent, and how Bliro enforces tool-level permissions through its AI agents.

Overview

Bliro connects to Outlook Calendar using user-delegated OAuth 2.0 against Microsoft Graph. Bliro acts on behalf of the signed-in user and cannot perform any calendar action that the user themselves is not permitted to perform. The integration is delivered through Bliro's registered Microsoft Enterprise Application – the same application used for Bliro's other Microsoft 365 integrations.

Application name: Bliro
Publisher: bliro GmbH (Microsoft verified publisher)

How the Integration Works

When a user connects Outlook Calendar in Bliro, the following happens:

Bliro initiates an OAuth 2.0 authorization request against login.microsoftonline.com.
The user signs in with their Microsoft work account and consents to the requested scopes.
Microsoft Entra ID issues an access token and a refresh token bound to the signed-in user.
Bliro uses the access token to call the Microsoft Graph API on behalf of that user, scoped to that user's mailbox and calendar permissions.
When the access token expires, Bliro silently refreshes it using the refresh token until the user disconnects or an administrator revokes consent.

All requests are scoped to the user's own identity. Bliro never holds an application-level (daemon) credential against your Microsoft 365 tenant.

Prerequisites

The user has a valid Microsoft 365 license with a mailbox and calendar.
Your Microsoft Entra ID tenant permits users to grant the Bliro Enterprise Application user-delegated permissions. If user consent is restricted in your tenant, a Microsoft Entra administrator must either pre-consent on behalf of the organization or grant the affected user the ability to consent.
The user is signed in to Bliro.

Setup: Connecting Bliro to Outlook Calendar

In Bliro, open Integrations and select Outlook Calendar.
Click Connect. Bliro redirects you to the Microsoft sign-in page (login.microsoftonline.com).
Pick the Microsoft work account whose calendar you want to connect.
Review the Permissions requested screen and click Accept. The requested permissions are listed in detail in the next section.
Bliro redirects you back to the integration page.
Configure the Tools & Permissions that Bliro is allowed to use on your behalf.

Requested Permissions (OAuth Scopes)

During consent, Bliro requests exactly the following ten scopes for the Outlook Calendar integration. Each is listed below with its purpose and justification.

Scope	Justification
openid	Standard OpenID Connect scope. Required to identify the user and link the Microsoft 365 account to the correct Bliro account.
offline_access	Allows Bliro to obtain a refresh token so it can renew the short-lived Microsoft Graph access token automatically. Without offline_access, the user would need to re-authenticate every time the access token expires (typically every hour), including for post-meeting actions that run after the user has closed the app. Does not grant any additional data access on its own.
email	Standard OpenID Connect scope that provides the user's primary email address, used as the unique identifier linking the Microsoft 365 account to the Bliro user account.
profile	Standard OpenID Connect scope that provides the user's name and basic profile information, used in the Bliro UI to personalize the experience.
User.Read	Reads the signed-in user's basic profile: display name, email address, timezone, and preferred language. Used to identify the user in audit logs, CRM attribution, and to schedule meetings in the user's local timezone.
Contacts.Read	Reads the user's saved customer contacts so Bliro can resolve names mentioned in voice commands to the correct email address. Read-only – Bliro does not create or modify contacts.
People.Read	Surfaces people the user frequently communicates with. Enables natural-language references to resolve to the right person even when the user has not explicitly saved them as a contact. Read-only.
User.ReadBasic.All	Reads basic profile information (name, email, job title) for other users in the user's own organization. Required when the user wants to schedule an internal handover meeting or cc a colleague. Access is limited to basic directory information and does not include calendar contents of colleagues.
Calendars.ReadWrite	Reads upcoming meetings so Bliro can brief the user before a visit, and creates, updates, or cancels calendar events when the user schedules follow-ups through voice or chat. Write access is required because creating a follow-up meeting after a customer visit is one of the core workflows Bliro automates. Without write access, the user would have to manually transfer every scheduled action from Bliro into Outlook.
Calendars.Read.Shared	Required to search for available meeting slots that account for calendars shared with the user (for example, a shared team calendar or a colleague's calendar the user has been granted visibility into). Ensures proposed meeting times do not conflict with shared commitments. Bliro only reads availability from shared calendars and does not modify them.

Tools and Permissions

Even with the Microsoft Graph scopes granted, Bliro does not perform any Outlook Calendar operation by default. Each individual action Bliro can take is modeled as a tool with its own permission level (Always Allow, Ask for Permission, or Deny), configured by an organization administrator.

Bliro currently ships a fixed set of predefined tools for Outlook Calendar covering event search, event creation, and contact search. Custom tool creation is not yet available for calendar integrations; only the predefined tools shipped with the integration can be enabled or disabled.

For a full explanation of the tool model, permission levels, the Ask for Permission flow, and how Bliro enforces denied tools, see AI Tools and Permissions.

Security Considerations

User-delegated only. Bliro never holds an application credential against your Microsoft 365 tenant. Every API call is authenticated as the user, and Microsoft Graph applies that user's mailbox, calendar, and directory permissions on each request.
Token storage. Refresh tokens are stored encrypted at rest. Access tokens are short-lived and held only for the duration of an operation.
Auditability in Microsoft 365. Because Bliro acts as the user, every read and write is attributed to that user in Microsoft 365 audit logs (Microsoft Purview / Unified Audit Log), making activity reviewable through native Microsoft tooling.
Conditional Access. Any Conditional Access policy your tenant applies to Microsoft Graph (MFA, compliant device, named locations, etc.) applies equally to Bliro's calls.

Disconnecting and Revoking Access

Users can disconnect Outlook Calendar at any time from the integration screen in Bliro by clicking Disconnect. This deletes the refresh token from Bliro's side and ends Bliro's ability to call Outlook on the user's behalf.

In addition, administrators can revoke Bliro's user-delegated permissions tenant-wide at any time via the Microsoft Entra portal under Enterprise applications → Bliro → Permissions, or per-user via https://myapps.microsoft.com.