article last updated 25th June 2026
Introduction
Customers deploying WorkPoint Express 365 must install an Enterprise Application in their Microsoft Entra tenant. During this process, administrators are prompted for consent for a set of tenant permissions. These permissions enable WorkPoint Express 365 to authenticate users and to interact with Microsoft 365 services such as Outlook and SharePoint, as well as WorkPoint services on the users' behalf.
In this article we will review the specific permissions WorkPoint Express 365 requires to operate and provide detail on how these are used in Express 365. This article is intended to provide tenant administrators with clarity of which specific permissions they will be required to consent to and how Express 365 is using these permissions to interact with Mail, SharePoint and WorkPoint services on the user's behalf.
How Express 365 uses Permissions
As shown in the communication diagram below, once WorkPoint Express 365 is installed and permissions are granted (see article), the application becomes available to users through Integrated Applications. Users can activate Express 365 as a task pane add-in within Outlook (1).
The Enterprise Application registered in the customer tenant (2) enables the add-in to use Nested App Authentication (NAA). This allows Express 365 to exchange the user's current Outlook session token for access tokens that are valid across Microsoft 365 services. These tokens are used to call Microsoft Graph for Mail and SharePoint, native SharePoint Online REST services, and the WorkPoint API (3) as the user navigates Express 365 and launches WorkPoint Automate processes.
Some WorkPoint specific requests are issued directly to the WorkPoint Web API (secured by its own Enterprise Application) which processes these requests on behalf of the signed-in user. It brokers operations such as handling mail items or launching WorkPoint Automate flows that query, create or update content in SharePoint Online within the tenant (4).
In a typical scenario, this flow results in email items being saved to WorkPoint entity sites. However, the behaviour is configurable. Using WorkPoint Automate, organisations can define alternative processes through a wide range of steps and actions.
The requests Express 365 issues directly to MS Graph and SharePoint REST services are predominantly read-only operations that allow WorkPoint Express 365 to efficiently interact directly with the customer's tenant (avoiding the need to broker indirectly through WorkPoint's own API). Typical examples are to retrieve information about Mail Item selections in the Outlook host application to provide context to WorkPoint Automate processes or to query and iterate large SharePoint lists.
Data update operations or WorkPoint Automate process initiations are routed through the WorkPoint 365 API and rely on the SharePoint Online consents granted in the WorkPoint 365 Web API application's own permissions (see article to follow), this means that the overall permission footprint of the WorkPoint Express 365 Enterprise Application is relatively modest - requiring only user delegated permissions to interact with the services as described above.
Permissions
In the this section, we outline the specific permissions used by the WorkPoint Express 365 Enterprise Application. As the platform evolves, additional permissions may be introduced to support new functionality.
We begin with the core permission set, followed by a review of existing and planned changes to this profile. This provides clarity on what access is required and how WorkPoint Express 365 uses these permissions within your tenant and across your data.
To provide our customers with clarity of the specific permissions our application requires, for consistency, each Application Registration is documented using a standardized permissions manifest presented in a table format for each requested claim and permission as described in the table below with an example permission.
| API / Claim | Type | Admin Consent | Used By | Used For |
|---|---|---|---|---|
| The distinct API and claim pair per Microsoft Application Registration Reference plus a brief description of capabilities (adapted from Microsoft Permissions Reference docs) | Indicates which type of permission the WorkPoint application is requesting. This will be one of the following values: Delegated Permissions that allow an application to act on behalf of a signed-in user. Access is constrained by both the permissions granted to the application and the effective privileges of the user, meaning the app cannot access data the user does not have rights to. Application Permissions that allow an application to act independently, without a signed-in user. Access is granted at the application level and is not limited by user context, enabling background or service-to-service operations across the tenant |
Indicates if Microsoft's Permission Specification requires tenant admin consent for this specific permission* | Primary use-cases of the permission in the context of WorkPoint operations. | Explanation of why or how the permissions are used to service WorkPoint Application Requests. |
| Example: | ||||
| Microsoft Graph | ||||
|
email View users' email address |
Delegated | N | Authentication | Used to retrieve the user’s email address / upn identity information.
Used in Authentication and Licensing flows. |
* Admin Consent: Per the Microsoft Permissions Reference documentation, specific permissions that are marked as requiring Administrator Consent and can only be granted by a tenant administrator. These permissions typically provide access to sensitive data, broad tenant resources, or administrative operations. While some permissions do not explicitly require admin consent - tenant-wide settings can often prevent users from approving all but a select white-list of low-risk permissions (if any). In practice, administrator approval is usually required to grant these permissions for all users in the organization. See the Microsoft documentation here for further details.
Express 365 Permissions
The following core permissions are requested by Express 365:
| API / Claim | Type | Admin Consent | Used By | Used For |
|---|---|---|---|---|
| Microsoft Graph | ||||
|
openid, profile, email Standard Microsoft OpenID Connect scopes that enable user authentication and provide access to basic identity information, including the user’s unique identifier, profile details, and primary email address, as part of the issued identity token.
|
Delegated |
N | User Authentication Licensing |
Enables OpenID Connect (OIDC) sign-in by allowing the app to authenticate the user and receive an ID token containing basic identity information. WorkPoint requests openid, profile, and email to enable user authentication and obtain basic identity information about the signed-in user.
These permissions are used to broker on-behalf-of user requests to SharePoint via GRAPH or SP-Rest EndPoints to access, create new or manipulate existing WorkPoint related data.
|
|
offline_access Maintain access to data you have given it access to |
Delegated | N | User Authentication | Allows WPE365 to obtain and use a refresh_ token, enabling the application to maintain user-authenticated sessions and request new access tokens for Microsoft Graph, SharePoint, and WorkPoint APIs without requiring repeated interactive user sign-in. |
|
Mail.Read Allows the app to read the signed-in user's mailbox. |
Delegated | N | Email Selection Email Journalization Processes |
For Express365: The application itself uses the Microsoft Graph mail endpoints to retrieve metadata for messages selected in the Outlook host application, such as messageId, subject, and sender. The message selection data is used for launch context for WorkPoint Automate processes and for the Locate Mails function in the Express365 UI.
When the user launches an Email Enabled WorkPoint Automate Process, the message selections are provided to the Automate engine as launch context parameters. The WorkPoint Automate action for UploadOutlookEmailsAndAttachments then uses the core WorkPoint365.WebAPI permission (with Mail.Read) to retrieve the messages and process the data according to the step configuration. Typically, this involves uploading Email messages as .eml files into Entity library locations. |
|
Files.ReadWrite > Files.ReadWrite.All * Allows the application to read, create, update, and delete files within the signed-in user’s own scope, typically limited to their OneDrive and directly associated file context. Access is constrained to what the user can access and is generally used when |
Delegated | N | Content Upload | With the June 2026 update, WorkPoint Express 365 introduced support for direct drag-and-drop of emails and attachments from Outlook into SharePoint document libraries, in addition to the existing WorkPoint Automate-based upload mechanisms. This functionality requires elevating the original Microsoft Graph delegated permission Files.ReadWrite to permission Files.ReadWrite.All, which allows the application to create and upload .eml files and attachments to libraries selected by the user within the WorkPoint Express 365 interface. All operations are performed in the context of the signed-in user, ensuring that access is constrained by the user’s existing SharePoint permissions. As a result, the application can only write to locations where the user already has sufficient rights, maintaining alignment with the principle of least privilege. |
|
User.Read > User.ReadWrite * Allows the app to update the profile properties for the signed-in user's work or school account |
Delegated | N | Preferences Application State |
Prior to the June 2026 update, WPE365 stored application state (e.g. Last Viewed Entity) and user preferences (e.g. Preferred Business Module View) in browser local storage scoped to the Outlook host. To support future cross-host scenarios (Word, Excel, PowerPoint), this state data is now stored as Microsoft Graph extension data enabling per-user, cloud-based persistence.
Preference and state data is written and retrieved via the following graph endpoint which requires User.ReadWrite access to manipulate.
https://graph.microsoft.com/me/extensions/com.workpoint.express365.preferencesIn the absence of this permission, WPE365 will gracefully revert to using local/browser web storage. State settings will be unique with each host application.
|
|
Sites.Read.All Read items in all site collections |
Delegated | N | SharePoint Data Access | This permission allows WorkPoint Express 365 to efficiently query and retrieve WorkPoint site data (Lists,
List Contents) directly from MS Graph and SharePoint SPO REST EndPoints. For example; when browsing a Business Module list in WPE365 - the list of WorkPoint Entities is retrieved from SharePoint via the MS.Graph endpoints such as the following: GET /sites/{site-id}/lists/{list-id}/items By querying SharePoint Online directly via Microsoft Graph and REST endpoints, WorkPoint Express 365 can optimise data retrieval for large datasets by leveraging native platform capabilities such as result paging and differential queries. This approach ensures high performance and responsiveness, while minimising consumption against tenant Resource Unit (RU) limits and reducing the risk of throttling within the customer’s Microsoft 365 environment. |
| WorkPoint365.WebAPI | ||||
|
user_impersonation Access WorkPoint365 WebAPI services as the current, signed-in user. |
Delegated | N/A** | WorkPoint Integration | Allows WPE365 to execute WorkPoint’s core APIs (on
behalf of user) to perform WorkPoint specific actions such as Create Entities,
Launch WorkPoint Automate Processes, Retrieve Relation data etc. (per the communication diagram in the preceding section). It is important to note that all WorkPoint Operations are executed on behalf of the current user meaning data access respects the end user's capabilities and permissions on the underlying SharePoint Online site structure. Operations that create or modify WorkPoint Entities and site structures via the WorkPoint API automatically adhere to the solution’s configuration rules, while efficiently triggering related system processes such as security replication, data aggregation, and inheritance.
Requests to the WorkPoint365 Web API are executed on behalf of the signed-in user. As a result, any SharePoint Online or Microsoft Graph operations are performed using the user’s own permissions, ensuring compliance with native SharePoint access controls. This also preserves auditing integrity, maintaining accurate “Created By” and “Modified By” metadata to reflect the originating user.
|
* Updated permissions (Prior > Current) - permissions that have changed as a result of an application update or release of new functionality. See description.
** Non-Microsoft permission / Admin Consent not applicable
Comments
0 comments
Please sign in to leave a comment.