M365 Permissions Required for Archival & Deletion (OneDrive, SharePoint, Outlook)

Customer-facing documentation for write-level Microsoft Graph permissions and how LightBeam uses them.

Purpose

This document outlines the Microsoft 365 (M365) application permissions required for LightBeam actions that modify content (archive, move, delete, and related write operations). It explains what each permission allows and maps the permission to LightBeam functionality so that IT/Security teams can review and approve with clarity.

Summary of Required Permissions

Product	Permission	Why it’s needed (high level)
OneDrive	Files.ReadWrite.All	To move/archive and delete files/folders, and to update file metadata when required.
SharePoint	Sites.ReadWrite.All	To move/archive and delete files/folders inside SharePoint sites/document libraries.
Outlook	Mail.ReadWrite	To modify mail state/content (e.g., move messages between folders, archive actions, apply supported updates).

How Archival and Deletion Works in LightBeam

Archival (files)

“Archive” is a write operation that typically involves one or more of the following:

• Move a file/folder to an archive location (different folder/path).

• Rename the item or update metadata to reflect archive state.

Because archiving changes the storage state of the item, Microsoft Graph requires read-write permissions for the target service.

Deletion (files)

“Delete” is a write operation that removes an item from its original location. Depending on tenant configuration and service behavior, deletion may place content into a recycle bin (soft delete) or permanently remove it when supported by the API and policy.

Deletion requires the application to have read-write permissions on the content scope.

Who can trigger archive/delete in LightBeam

Although the Azure AD application permission is tenant-scoped, LightBeam executes archive/delete actions only when initiated by an authorized LightBeam user.

Auditability

Actions can be audited through:

• LightBeam action history/logs (initiator, timestamp, target, outcome).

Permission-by-Permission Explanation

OneDrive — Files.ReadWrite.All

What the permission allows

Files.ReadWrite.All allows the application to read and write files and folders. This includes the ability to create, update, move, rename, and delete items, as well as read metadata and content when required.

Why LightBeam needs it

LightBeam uses this permission to perform file actions that modify OneDrive content:

• Archive: move items into an archive folder/path, rename, or apply supported metadata updates.

• Delete: delete files/folders when a retention/remediation action is executed.

Impact if not granted

Archive and delete actions for OneDrive will fail due to insufficient privileges.

SharePoint — Sites.ReadWrite.All

What the permission allows

Sites.ReadWrite.All allows the application to read and write content across SharePoint sites in the tenant, subject to tenant policies. It enables the application to interact with site document libraries and perform operations such as create, update, move, rename, and delete.

Why LightBeam needs it

LightBeam uses this permission to perform file actions that modify SharePoint content:

• Archive: move items into an archive location within a site/library, rename, or apply supported metadata updates.

• Delete: delete items as part of remediation/retention actions.

Impact if not granted

Archive and delete actions for SharePoint will fail. Any workflow that requires moving or deleting content in SharePoint cannot complete.

Outlook — Mail.ReadWrite

What the permission allows

Mail.ReadWrite allows the application to read and modify mailbox messages. Depending on supported Graph operations, this can include moving messages between folders, changing message properties supported by the API, and updating message state (e.g., read/unread).

Why LightBeam needs it

LightBeam uses this permission only for mail workflows that require write operations, such as:

• Archive: move a message to an archive folder or execute a workflow that changes message organization/state.

• Other write operations that are explicitly initiated/approved within LightBeam.

Impact if not granted

Mail write actions (such as moving messages to an archive folder) will fail. Read-only workflows may still be possible with read permissions.

Are these write permissions risky?

These are powerful permissions because they allow modification of content. LightBeam mitigates risk by executing actions only when initiated by authorized LightBeam roles/workflows, maintaining an audit trail, and using permissions only for the explicitly requested operations.