Symptom
To use Microsoft Graph API, the user or administrator must grant it the necessary permissions.
This document lists the delegated and application permissions exposed by Microsoft Graph
Environment
SAP Cloud for Customer
Resolution
There are two types of permissions:
Delegated permissions — the application acts on behalf of a signed-in user and works with that user's data. These are used by the Outlook add-in and by server-side synchronization when End user sign-in is configured.
Application permissions — the synchronization service operates in the background without requiring individual users to remain signed in. These are used for App-only synchronization.
Microsoft displays the permissions registered for the application on the consent screen. The functionality actually used depends on the synchronization configuration.
| Type | Permission | What it allows / Why it is needed |
|---|---|---|
| Delegated | Access mailboxes as the signed-in user via Exchange Web Services | Allows access to the signed-in user's mailbox through EWS. This supports existing EWS-based functionality during the transition to Microsoft Graph. It does not provide access to other users' mailboxes. |
| Delegated | Have full access to user calendars | Allows calendar items to be read, created, updated and deleted for the signed-in user. This is required to synchronize supported calendar activities between Outlook and SAP Sales Cloud. |
| Delegated | Have full access to user contacts | Allows the signed-in user's Outlook contacts to be managed for contact synchronization with SAP Sales Cloud. |
| Delegated | Read user mail | Allows the application to read emails in the signed-in user's mailbox, for example so the Outlook add-in can process the currently opened email and relate it to SAP records. It does not allow sending emails. |
| Delegated | Read and write access to user mail | Allows emails and their properties to be processed or updated, for example by applying categories used by the integration. It does not grant permission to send emails on the user's behalf. |
| Delegated | Maintain access to data you have given it access to | Keeps the authenticated connection available without requiring users to sign in repeatedly. It does not grant access to any additional data. |
| Delegated | Create, read, update and delete user's tasks and task lists | Allows supported Outlook/Microsoft To Do tasks to be synchronized with SAP Sales Cloud. |
| Delegated | Sign in and read user profile | Allows the application to identify the signed-in user using basic information such as name, email address and user ID. |
| Delegated | Read all users' basic profiles | Allows basic directory information such as names and email addresses to be retrieved, for example to identify meeting participants and match them with SAP employees. It does not provide access to their mailboxes. |
| Application | Read and write calendars in all mailboxes | Allows the background synchronization service to manage calendar items for users participating in synchronization without requiring each user to remain signed in. |
| Application | Read and write contacts in all mailboxes | Allows contacts to be synchronized in the background for the relevant users. |
| Application | Read and write mail in all mailboxes | Allows the background service to process emails and update properties required for synchronization, such as categories. It does not grant permission to send emails. |
| Application | Read and write all users' tasks and task lists | Allows supported tasks to be synchronized in the background without requiring individual user authentication. |
| Application | Read all users' full profiles | Allows the service to retrieve directory information required to correctly identify users, including their email aliases, and match their Microsoft 365 mailbox with the appropriate SAP user. |
Why does Microsoft say “all mailboxes”?
This wording is part of Microsoft's Application permission model. With App-only authentication, permissions are granted by the Microsoft 365 administrator at the organization level rather than individually by every mailbox owner.
This does not necessarily mean that every mailbox must remain accessible to the application. Microsoft provides administrative mechanisms, such as Application RBAC and Application Access Policies, that can be used to restrict Exchange application access to the required mailboxes. All mailboxes that need to participate in synchronization must remain within the configured scope.
Is there an alternative?
Yes. If you prefer not to grant Application permissions, synchronization can instead use End user sign-in with Delegated permissions.
In this configuration, each user connects their own mailbox individually and the application operates with that user's permissions. The trade-off is that each user must authenticate separately, and synchronization depends on their authentication remaining valid.
In comparison, App-only authentication allows synchronization to run continuously in the background without requiring individual users to maintain their own connection.
Most importantly, the requested permissions do not include permission to send emails on behalf of users, and profile permissions do not provide access to users' email or calendar content.
I hope this provides more clarity regarding the requested permissions. If your Microsoft 365 or security team has concerns about any specific permission, please let us know which one and we will be happy to clarify its purpose in more detail.
What happens when End user sign-in is selected?
Please note that selecting End user sign-in does not mean that Microsoft will not display a permission request. It only determines that synchronization will use the individual user's Delegated permissions rather than Application permissions.
When a user signs in for the first time, Microsoft may still display a Permissions requested screen asking for the delegated permissions required to access that user's own mailbox, calendar, contacts, tasks and profile.
Whether the user can accept these permissions themselves depends on your organization's Microsoft Entra consent policy. If user consent is allowed, the user can accept the requested delegated permissions and continue. If user consent is restricted, Microsoft may instead display “Need admin approval,” in which case a Microsoft 365 administrator must grant consent.
If an administrator has already granted the required delegated permissions on behalf of the organization, users should normally be able to sign in without having to approve the permissions individually.
Importantly, this permission prompt does not change End user sign-in into App-only authentication. The synchronization still operates using the individual user's delegated access.
See Also
Microsoft article: Microsoft Graph permissions reference
Keywords
Graph API; Server Side; Addon; Add-in; Write Access; Read access; SSI; C4C; Microsoft Authorization; Permission; Full Access , KBA , LOD-CRM-GW-SCC , Invisible CRM - Smart Cloud Connect Solution , How To
SAP Knowledge Base Article - Public