Troubleshooting¶

For general questions about how features behave, see the FAQ. This page covers diagnosing failures -- what an error means and what to check.

If nothing here matches what you are seeing, file an issue with the browser and OS you are using, the page you were on, and the exact error text.

Sign-in and consent¶

Popup blocked or closes immediately¶

Symptom: Clicking Sign in with Microsoft does nothing, or a browser notification appears saying a popup was blocked.

Cause: The app uses loginPopup() for the OAuth2 PKCE flow. Browsers block popups not triggered directly by a user gesture, and some popup blockers also block the intermediate redirect back to the app.

Check: Look for a blocked-popup icon in the address bar.

Fix: Allow popups for the app's domain and click Sign in with Microsoft again.

Consent prompt shows the wrong permissions, or none at all¶

Symptom: The consent screen lists fewer permissions than expected, or the app behaves as if you were never asked for consent.

Cause: The app uses a tiered, incremental consent model (see Permissions). Only Tier 1 scopes -- User.Read, DeviceManagementApps.ReadWrite.All, DeviceManagementConfiguration.ReadWrite.All, Group.Read.All -- are requested at sign-in. Higher tiers are requested only when you navigate to a feature that needs them, as a separate popup.

Check: Confirm which page you were on when the prompt appeared, and cross-reference it against the scope-to-feature table.

Fix: Accept the prompt for the feature you are trying to use. If no prompt appears at all, your organisation may require admin consent -- see below.

"Need admin approval" or the consent popup closes with an error¶

Symptom: Microsoft's consent screen shows "Need admin approval" instead of an Accept button, or the popup closes without granting anything.

Cause: DeviceManagementApps.ReadWrite.All, DeviceManagementConfiguration.ReadWrite.All, and Group.Read.All are admin-level Graph scopes. If your tenant has user consent disabled for admin-level permissions (the default in many hardened tenants), an individual user cannot self-consent, regardless of how many times they click Accept.

Fix: A Global Administrator or Intune Administrator must grant admin consent for the app registration once, tenant-wide. From the Azure Portal: App registrations > your app > API permissions > Grant admin consent. See Granting Additional Permissions.

Signed in, but scopes reset after every page refresh¶

Symptom: You have to re-consent to a tier you already granted, every session.

Cause: Granted-scope tracking is stored in localStorage under the key intune-granted-scopes (see Authentication - Scope accumulation). If the browser is in a private/incognito window, has third-party storage restrictions, or clears site data on close, that key does not persist.

Check: Confirm you are not in a private browsing window and that the site is not excluded from storage in your browser's privacy settings.

"Insufficient permissions" and Graph errors¶

Insufficient permissions / 403 on a specific action¶

Symptom: An action fails with an insufficient-permissions message, but you are signed in.

Cause: The Graph client throws a typed PermissionError for any 403 response (see Graph API Client - PermissionError). This means the request reached Microsoft Graph and was rejected for lacking a scope -- distinct from a 401, which means the token itself was rejected.

Check: Go to Settings and compare the granted tiers against what the operation needs:

Fix: Click Grant Permissions on the Settings page for the missing tier. If the tier already shows as granted, the tenant-level admin consent may not have propagated yet, or a tenant admin may have revoked consent centrally -- see Revoking Permissions for where that is controlled.

Session expires mid-task, or "Your session has expired. Please sign in again."¶

Symptom: An in-progress action fails and you are prompted to sign in again.

Cause: Access tokens last approximately one hour. MSAL.js retries silently via acquireTokenSilent() using the cached refresh token first; only if that fails (refresh token expired, revoked, or a new scope needs interactive consent) does the app fall back to acquireTokenPopup(). If that also fails, the Graph client raises AuthenticationError and toFriendlyMessage() renders it as "Your session has expired. Please sign in again." (see Graph API Client - AuthenticationError).

Fix: Sign in again. Wizard state is kept in memory (not lost), so you can resume the Bulk Assignment flow after re-authenticating -- see the FAQ.

Rate limited / "Microsoft Graph is rate limiting requests"¶

Symptom: A bulk operation slows down or a friendly rate-limit message appears.

Cause: The Graph client retries 429 responses automatically -- up to 3 attempts, sleeping for the Retry-After duration returned by Graph (defaulting to 5 seconds if the header is missing). Batch requests handle 429 per-item: failed items are collected, the client waits for the longest Retry-After among them, and resubmits just those items, also up to 3 total attempts (see Graph API Client).

Check: This is expected behaviour under load, not a bug -- large bulk-assignment runs against many apps/profiles and groups generate a proportionally large number of Graph calls.

Fix: Nothing to do for occasional throttling; the client retries transparently. If a RateLimitError still surfaces after all retries are exhausted, wait and retry the operation, or reduce the number of items selected in a single wizard run.

Wrong tenant, or app/group data doesn't match what you expect¶

Symptom: The apps, profiles, or groups shown don't match the tenant you intended to sign into.

Cause: The app's MSAL authority is configured as https://login.microsoftonline.com/common (see Authentication - MSAL Configuration), which is multi-tenant: it allows sign-in to any Microsoft Entra ID tenant that has consented to the app registration, and Microsoft's account picker may default to a different account/tenant than the one you meant to use.

Fix: Sign out (clears the local MSAL cache and any tracked permissions -- see Sign-out), then sign in again and pick the correct account at the Microsoft login screen. If you use multiple work accounts, check which one is active in the browser before signing in.

GCC, DoD, or other sovereign cloud tenant¶

Symptom: Sign-in or Graph calls fail entirely, or the app cannot reach your tenant at all.

Cause: The app is hardcoded to the Microsoft public cloud endpoints (login.microsoftonline.com / graph.microsoft.com). GCC High, DoD, and other sovereign clouds use different authority and Graph endpoints.

Fix: Not supported without modifying the MSAL and Graph client configuration in source -- see the FAQ.

Assignment and data issues¶

Assignment write appears to have removed unrelated assignments¶

Symptom: After running a bulk assignment, a group's existing assignment for an unrelated app changed or disappeared.

Cause: The Graph assign endpoint replaces the entire assignment list for an item on every write. The app is designed to fetch current assignments first and merge in your changes (see Architecture - Bulk Assignment Execution Flow), but this only covers what the merge step actually saw at fetch time -- a concurrent change made by someone else (or in the Intune portal) between your fetch and your apply is not accounted for.

Fix: Always review the diff on the Review step before applying (see Bulk Assignment Wizard), and avoid running two bulk operations against overlapping items at the same time.

Status page is missing profiles you know have deployment errors¶

Symptom: A Settings Catalog profile with known deployment issues does not appear on the Deployment Status page.

Cause: The device status overview endpoint the app uses only works for legacy device configuration profiles. Settings Catalog policies return a 404 from that endpoint and are silently excluded -- see Graph API Client - Known API Limitations.

Fix: None from within the app; this is a Graph API limitation, not a filter you can change. Check the profile's status directly in the Intune admin center instead.

CSV import rejects rows¶

Symptom: Importing a CSV shows validation errors instead of pre-populating the wizard.

Cause: See the validation table in CSV Import & Export -- most failures are a missing required header, an ItemType/TargetType value outside the allowed set, or an ItemId/GroupId that does not resolve (and no exact-match ItemName/GroupName fallback either).

Fix: Check the per-row error messages shown after import, and prefer GUIDs over names -- name resolution requires an exact, unique match. See CSV - Name-Based Resolution.

Where to look for more detail¶

• FAQ -- common behavioural questions (does it overwrite assignments, can I set different intents per app, browser support, and more)
• Graph API Client -- the client's retry logic and full error type hierarchy
• Permissions -- the full scope-tier breakdown