An icehouse inventory app requests a high-privilege Microsoft Graph permission, and ordinary growers cannot complete consent. What should the developer arrange?

High-privilege Microsoft Graph permissions often require tenant administrator consent. Ordinary growers at the icehouse inventory app cannot approve those permission classes in the user consent prompt. The developer must obtain admin consent—via the Entra portal, an admin consent URL, or an approved enterprise app workflow—before the feature that depends on that permission can run for users in the tenant.

Switching the permission to a storage account SAS fails because Graph directory and mailbox data are not exposed through Storage SAS. Changing credential types does not remove Graph’s consent requirements; it simply abandons the Graph API the feature needs.

Disabling consent and hard-coding a tenant-wide client secret in the browser fails on security and platform rules. Browser-exposed secrets are public, client secrets belong to confidential clients on the server, and skipping consent does not grant Graph permissions. You still need an authorized token with the right scopes or roles.

Replacing Graph with a local password table fails as an identity anti-pattern and does not solve the stated consent problem. Rolling your own credential store abandons Entra authentication, creates password-handling risk, and still leaves you without a supported Graph integration for Microsoft 365 profile and directory data.

Exam caveat: some permissions are “admin-only” for consent even when the eventual runtime call uses delegated permissions. Admin consent is about who may approve the grant for the tenant, not only about application permissions.

Operational check: in the app registration’s API permissions, confirm the high-privilege Graph permission shows granted for the tenant (admin consent), then acquire a token and verify the expected scp or roles claim before releasing the grower-facing feature.