The Microsoft 365 integration connects your organization's email and calendar data to Backstory through application-based access. This allows administrators to onboard teams in the background and control whose activities are captured from the Microsoft admin panel.
Microsoft is transitioning from Application Access Policy to Role-Based Access Control (RBAC). We support both methods to accommodate new and existing customers.
What You Can Do
Connect Outlook email and calendar to auto-capture team activity data
Choose between RBAC or Application Access Policy integration methods
Control data access by specifying which users and groups Backstory can see
Maintain secure read-only access that is not affected by password changes
Choose Your Integration Method
Method 1: RBAC (Recommended)
RBAC is Microsoft's future-proof access model and our default for new integrations. It lets you explicitly define which users or groups Backstory can access, rather than granting tenant-wide access.
Why we recommend RBAC: According to Microsoft's documentation, App Access Policies has been replaced by Role Based Access Control for Applications. New access configuration should not use Application Access Policies since this feature will have deprecation announced in the future.
Best for: All new Backstory customers and existing customers who want to proactively prepare for the future.
Key benefits:
Centralized administration: A Microsoft 365 administrator grants and manages access from the Microsoft admin environment.
Reliable and continuous data availability: Unlike user-driven (delegated) access, application access does not break when users change passwords, leave the company, or revoke consent.
No credential sharing: Backstory never receives or stores administrator credentials. Microsoft issues time-bound OAuth 2.0 access tokens that allow Backstory to operate within the permissions explicitly granted.
Read-only by design: Backstory does not require write access to any Microsoft 365 resources. Only read-only permissions for email and calendar data are used.
Flexible scoping: Although application permissions are granted at the tenant level, RBAC allows you to strictly limit which users' data Backstory can access.
Method 2: Application Access Policy (Legacy)
Application Access Policy is the original integration method that many existing Backstory customers currently use. While Microsoft plans to deprecate this model eventually (no date announced), Backstory continues to fully support it.
Application Access Policies allow Microsoft Entra ID Global Administrators to explicitly control which mailboxes and calendars Backstory is permitted to access, even when application-level permissions are granted. This is typically achieved by creating a Microsoft 365 security group containing in-scope users, applying an Application Access Policy that allows Backstory to access only that group, and prohibiting access to all other mailboxes and calendars by default.
Best for: Existing customers who aren't ready to migrate yet.
Application-Based Access
Backstory uses Microsoft Graph API with OAuth 2.0 and application-based access, not delegated user permissions. This model allows Backstory to securely ingest email and calendar data without relying on individual user authorization. Instead, access is granted centrally by a Microsoft 365 administrator and applies consistently across the organization.
Authorization and Permissions
For application access, a Microsoft Entra ID Global Administrator (for Application Access Policy) or an administrator with Exchange Administrator or Role Management permissions (for RBAC) must authorize Backstory using Microsoft's OAuth 2.0 authorization flow.
During setup, the administrator will be asked to consent to specific read-only Microsoft Graph permissions required for email and calendar ingestion.
Backstory:
Does not require write access to any resources
Uses granted permissions solely to provide Backstory functionality
Operates only within the scope defined by Application Access Policies or RBAC
By default, Microsoft Graph application permissions apply tenant-wide, but Application Access Policies and RBAC allow administrators to limit access to specific users or groups.
How to Set Up RBAC (Recommended)
During this integration, the following Azure Enterprise Application will be installed:
Backstory Activities Connector
Application (Client) ID: 080d0dfd-4b56-406a-b263-7bc848d82019
This application is used to access Exchange Online mail and calendar data via RBAC
Generate Authorization URL
A Backstory administrator must complete the following steps:
Log into Backstory as an administrator.
Click the grid icon in the top left corner.
Select Admin Panel.
In the left navigation menu under Data Ingestion, click Email and Calendar.
Open the Office 365 tab.
Click Authorize Team Access.
Keep the RBAC option selected (default selection).
Copy the generated authorization URL and send it to your Microsoft 365 administrator.
Click Done.
Grant Admin Consent
A Microsoft 365 administrator with Exchange Administrator or Role Management permissions must complete the following steps:
Open the authorization URL provided by your Backstory administrator.
Sign in with your Microsoft admin account.
Review the permissions requested by the Backstory Activities Connector.
Click Accept to grant admin consent.
Verify Installation
A Microsoft 365 administrator must complete the following steps:
Navigate to the Azure Portal.
Go to Enterprise Applications.
Confirm that Backstory Activities Connector appears in the application list.
Configure User Access
A Microsoft 365 administrator must complete the following steps. This critical step restricts Backstory access to only the users or groups you specify.
Prerequisites:
Exchange Administrator or Role Management role
PowerShell installed on your computer
Exchange Online PowerShell module
Connect to Exchange Online PowerShell
Open PowerShell and install the Exchange Online module:
Install-Module ExchangeOnlineManagement
Import the module:
Import-Module ExchangeOnlineManagement -ErrorAction Stop
Connect to Exchange Online:
Connect-ExchangeOnline
Sign in with your Exchange admin account when prompted.
Retrieve Application Identifiers
In the Azure Portal, navigate to Enterprise Applications > Backstory Activities Connector.
Copy the Object ID of the application.
Create a Service Principal
New-ServicePrincipal `
-AppId 080d0dfd-4b56-406a-b263-7bc848d82019 `
-ObjectId <OBJECT_ID_FROM_AZURE> `
-DisplayName SP_People_Connector
Assign RBAC Roles
You can scope access using Administrative Units or Microsoft Groups. The examples below use Administrative Units.
Assign read-only permissions for Mail:
New-ManagementRoleAssignment `
-App <OBJECT_ID_FROM_AZURE> `
-Role "Application Mail.Read" `
-RecipientAdministrativeUnitScope <ADMIN_UNIT_ID> `
-Name MRA_People_Connector_Mail
Assign read-only permissions for Calendars:
New-ManagementRoleAssignment `
-App <OBJECT_ID_FROM_AZURE> `
-Role "Application Calendars.Read" `
-RecipientAdministrativeUnitScope <ADMIN_UNIT_ID> `
-Name MRA_People_Connector_Calendar
Verify Authorization
Test the configuration by testing access with a user's email address:
Test-ServicePrincipalAuthorization `
-Identity <OBJECT_ID_FROM_AZURE> `
-Resource user@company.com
Propagation Delay: RBAC role assignments may take up to 30 minutes to become effective in Microsoft Graph API calls.
How to Set Up Application Access Policy (Legacy)
Use this option only if you are an existing customer not ready to migrate to RBAC. This method uses Microsoft Graph API with Application Access Policies to restrict access to specific mailboxes.
The following process needs to be performed by a user with Microsoft Entra ID Global Admin permissions.
During this integration, the following Azure Enterprise Application will be installed:
Backstory Graph
Application (Client) ID: 6135b4c8-8900-475f-84db-b8ee65fbb329
This application is used to access Exchange Online mail and calendar data via Application Access Policy
Limit Backstory Application Access to Certain Users
It is recommended to limit the users' scope before installing the Backstory Azure Application to simplify the setup process.
To limit the Backstory application access to a specific set of mailboxes, use the New-ApplicationAccessPolicy PowerShell cmdlet to configure access control.
Create a Mail-Enabled Security Group
First, create a mail-enabled security group. You will create a restrictive policy that prevents Backstory access to any mailbox not within this security group.
Connect to Exchange Online PowerShell
Connect to Exchange Online PowerShell. For details, see Connect to Exchange Online PowerShell.
Create Application Access Policy
Set up an application access policy to limit Backstory's access to the mail-enabled security group. Below is an example command - you will need to replace PolicyScopeGroupId and Description arguments with your mail-enabled security group information, while AppId argument should stay the same (this is Backstory's application):
New-ApplicationAccessPolicy `
-AppId 6135b4c8-8900-475f-84db-b8ee65fbb329 `
-PolicyScopeGroupId EvenUsers@contoso.com `
-AccessRight RestrictAccess `
-Description "Restrict this app to members of distribution group EvenUsers."
Test the Application Access Policy
Test the newly created application access policy. The output of this command will indicate whether the enterprise application has access to user1@contoso.com mailbox:
Test-ApplicationAccessPolicy `
-Identity user1@contoso.com `
-AppId 6135b4c8-8900-475f-84db-b8ee65fbb329
Note: Changes to application access policies can take up to 30 minutes to take effect in Microsoft Graph REST API calls.
Additional permissions configuration: You can further limit the specific access permissions, though this is unnecessary because of OAuth's scoping. To do so, see Supported permissions and additional resources.
Authorize Team Access
Log into Backstory as an administrator.
Click the grid icon in the top left corner.
Select Admin Panel.
In the left navigation menu under Data Ingestion, click Email and Calendar.
Open the Office 365 tab.
Click Authorize Team Access.
Select Application Access Policy.
Copy the generated authorization URL and send it to your Microsoft 365 administrator.
Click Done.
Grant Admin Consent
A Microsoft 365 administrator with Exchange Administrator or Role Management permissions must complete the following steps:
Open the authorization URL provided by your Backstory administrator.
Sign in with your Microsoft admin account.
Review the permissions requested by the Backstory Activities Connector.
Click Accept to grant admin consent.
How to Migrate from Application Access Policy to RBAC
Migration is optional until Microsoft announces a deprecation date, but we recommend migrating proactively.
Log into Backstory as an administrator.
Click the grid icon in the top left corner.
Select Admin Panel.
In the left navigation menu under Data Ingestion, click Email and Calendar.
Open the Office 365 tab.
Click Re-Authorize Team Access.
Select RBAC.
Complete the RBAC setup steps outlined above.
(Optional) Remove the legacy Application Access Policy app after verifying the new integration works via Microsoft Azure Portal.
Frequently Asked Questions
Will the connection break if users change passwords or leave the company?
No. Because access is application-based rather than user-based, password changes and account deactivation don't affect the integration.
Can Backstory modify or delete emails or calendar events?
No. Backstory only has read-only access to email and calendar data.
Why can't my users authenticate after granting admin consent?
Some organizations use customized authorization flows instead of the standard Microsoft 365 Single Sign-On. If users are unable to authenticate after admin consent has been granted, have your Microsoft Entra ID Global Administrator log into Backstory first. This will allow other users to authenticate successfully.
What should I do if I get an error when trying to grant admin consent?
The authorization URL uses the /common endpoint by default, which works for most tenants and allows Microsoft to automatically resolve the correct directory.
If you encounter an error during consent, the /common endpoint may not be supported or may be restricted in your Microsoft 365 environment. To fix this, replace /common/ in the authorization URL with your specific Azure AD Tenant ID (e.g., /<TENANT_ID>/), then try again.
Need Help?
Reach out to your CSM or email support@backstory.ai.