Skip to content
Go to aheadintranet.com
  • There are no suggestions because the search field is empty.

Understanding Permissions Requested by the ahead intranet App

The ahead intranet app integrates deeply with Microsoft 365 and uses the Microsoft Graph API to provide features like people search, document discovery, personalized news, and group-based access control. 

To enable these features, the app requests certain read-only permissions that must be approved by a Global Administrator in Microsoft Entra ID (formerly Azure AD). 

All requested permissions follow Microsoft’s standard enterprise app consent model and are read-only — the app cannot modify, delete, or write any data in your tenant. 

Frequently Asked Questions (FAQ) 

1. Why does the app need these permissions?


The app relies on Microsoft Graph to connect user data, SharePoint content, and external information sources. 

Each permission corresponds to a specific function — mainly to allow employees to search, navigate, and access content and people within their organization. 

These are standard permissions for enterprise-grade intranet and employee engagement tools. 

Think of what an employee expects from a modern intranet: they should be able to see company news (possibly targeted by role or group), search across all documents and pages they have access to, find colleagues in the directory, see organizational announcements, and maybe even pull in data from other business systems – all without leaving the intranet. Achieving this integration requires the app to talk to multiple Microsoft 365 services (Azure AD for user info, SharePoint for content, Microsoft Search for connectors, etc.). Consequently, multiple Graph API permissions are necessary. Granting consent to a bundle of permissions like this is a one-time setup that a Global Admin performs to approve the app for the whole organization. This “admin consent” model is how Microsoft designed third-party apps to integrate securely, rather than, say, asking every end user to individually consent to each permission (which isn’t feasible for org-wide features). 

The bottom line is that the set of permissions ahead is asking for is standard for its class of application. It’s not an outlier; it’s aligned with what the functionality demands.

2. Which permissions are requested and why?

Sign in and read user profile (User.Read) – Type: Delegated (APIs: MS Graph / Azure AD) 

  • Definition: Allows users to sign in to the app, and allows the app to read the profile of signed-in users. It also allows the app to read basic company information of signed-in users. 
  • Purpose: Authenticates users and reads their basic profile (name, email, job title, photo). 
  • Used for: Sign-in and personalization of the intranet experience. 
  • Standard Practice: Required by nearly every Microsoft 365-integrated app. 

Read all users’ full profiles (User.Read.All) – Type: Application / Delegated 

  • Definition: Allows the app to read the full set of profile properties, reports, and managers of other users in your organization, on behalf of the signed-in user but also on application level. 
  • Purpose: Allows the app to read the full set of profile properties of other users. 
  • Used for: People search, org charts, showing profile cards, and collaboration features. 
  • Scope: Read-only, used both in context of the signed-in user and the application or for caching employee directories/profiles in ahead intranet. 
  • Standard Practice: Common in intranet, HR, and collaboration apps (e.g. Viva, Dynamics, ServiceNow integrations). 

Read directory data (Directory.Read.All) – Type: Application / Delegated 

  • Definition: Allows the app to read data in your organization’s directory, such as users, groups and apps – also without a signed in user. 
  • Purpose: Reads users, groups, and directory structure from Entra ID. 
  • Used for: Verifying that the signed-in user belongs to your organization and the correct permission group in Entra ID; and for the application to target news or content by Entra ID groups. 
  • Scope: Read-only. Used both interactively and in background services for notifications or synchronization. 
  • Standard Practice: Normal for any app using Entra ID to manage user targeting or access control. 

Read items in all site collections (Sites.Read.All) – Type: Delegated 

  • Definition: Allows the application to read documents and list items in all site collections on behalf of the signed-in user. 
  • Purpose: Enables search and retrieval of documents and pages from SharePoint Online. 
  • Used for: Company-wide document search and surfacing intranet content a user already has access to. 
  • Scope: Delegated — the app can only read what the signed-in user is allowed to access. 
  • Standard Practice: Common for apps integrating SharePoint or Microsoft Search.c 

Read items in external datasets (ExternalItem.Read.All) – Type: Delegated 

  • Definition: Allows the app to read external datasets and content, on behalf of the signed-in user. 
  • Purpose: Reads external content indexed in Microsoft Search via Graph Connectors. 
  • Used for: Including external systems (e.g. ServiceNow, CRM, file systems) in intranet search results. 
  • Scope: Read-only. Used only if your tenant uses Graph Connectors. 
  • Standard Practice: Typical for enterprise intranet solutions offering unified search experiences. 

3. Why are some permissions listed “with” and “without” a signed-in user?

Microsoft distinguishes between: 

  • Delegated permissions – Used when a user is signed in (on behalf of that user, in his / her context). 
  • Application permissions – Used by the app itself for background tasks (e.g. caching or notifications). 

Both are normal for enterprise apps. The ahead intranet uses application permissions to verify access and deliver timely updates even when users aren’t active.

4. Is this level of access safe?

Yes. All permissions are read-only and operate within Microsoft’s Graph security model. The app: 

  • Cannot alter or delete data. 
  • Only reads data necessary for its features. 
  • Has been registered as a verified enterprise app in Microsoft Entra ID. 
  • Requires explicit admin consent, visible and controllable at all times via the Microsoft 365 Admin Center. 

This approach is standard Microsoft practice for enterprise integrations. 

5. What data does the app actually store?

The ahead intranet stores a minimal, read-only subset of Entra ID data: 

  • User ID and name, as well as defined attributes in Entra ID 
  • Group memberships relevant to intranet targeting. 

No sensitive or personal data is stored beyond what’s necessary to display content and enable collaboration unless otherwise defined. 

Conclusion 

All requested permissions are essential for providing a seamless, intelligent intranet experience within Microsoft 365. 

They are: 

  • Standard for enterprise-grade integrations. 
  • Read-only and non-invasive. 
  • Required to verify user identity, enable enterprise search, and personalize content. 

Granting these permissions follows Microsoft’s recommended pattern for secure, organization-wide app consent. 

By approving them, you allow the ahead intranet to fully function while maintaining complete control through your Entra ID admin settings.

Contact 

In case of any questions, do not hesitate to contact us directly: 

ahead AG 
Schanzenstrasse 4C 
3008 Bern 

Support: support@aheadintranet.com 

Security and Compliance Overview: https://aheadintranet.com/en/security-and-compliance