Microsoft 365 Integrated Apps: Deploying Office add-in from AppSource fails with "Invalid Resource Specific Permission"

Rich Long 0 Reputation points
2026-09-02T08:17:00.9333333+00:00

Service

Microsoft 365 Integrated Apps deployment / AppSource Marketplace / Unified manifest for Microsoft 365

Scenario

We publish an Outlook add-in to AppSource (listing). The add-in uses a unified manifest with the following authorization.permissions.resourceSpecific permissions:

"authorization": {
  "permissions": {
    "resourceSpecific": [
      { "name": "MailboxItem.ReadWrite.User", "type": "Delegated" },
      { "name": "Mailbox.SharedFolder", "type": "Delegated" },
      { "name": "Document.ReadWrite.User", "type": "Delegated" }
    ]
  }
}

All three permission names are documented as valid for Office add-ins:

When a customer's tenant admin attempts to deploy the add-in, the deployment is blocked with an error dialog.

Result

The admin sees the following error:

Invalid Resource Specific Permission Please make sure all the permissions under authorization.permissions.resourceSpecific are valid.

(Screenshot attached)

The deployment cannot proceed.

Environment

  • Deployment path: AppSource Marketplace → Microsoft 365 admin deployment flow
  • Admin role: Global Administrator
  • Tenant: Microsoft 365 Business (customer tenant, not developer tenant)
  • Entra ID app registration: all Microsoft Graph delegated permissions granted and consented

Troubleshooting

  1. Verified all three permission names match the official documentation exactly.
  2. Confirmed the Entra ID app registration has admin consent granted for all required Graph permissions.
  3. The manifest passed AppSource validation and was accepted for publication — the error only occurs at the tenant admin deployment step.
  4. This appears to be a known issue where the Teams deployment validator checks Office add-in RSC permission names against the Teams-only RSC registry and rejects valid Office-specific names like Mailbox.SharedFolder.

Related reports:

Question

Is this a known bug in the Integrated Apps / Teams deployment validator not recognising Office add-in RSC permissions in unified manifests? Is there a workaround that allows tenant admins to deploy the add-in from AppSource, or does the manifest need to be restructured?This is blocking an urgent customer deployment for our add-in, we would appreciate any help.

Microsoft 365 and Office | Development | Microsoft 365 App Publishing
0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Demi Nguyen 1,505 Reputation points Independent Advisor
    2026-09-02T10:31:11.8466667+00:00

    Hello Rich Long,

    Thank you for providing such a detailed description of the deployment behavior and the troubleshooting already completed.

    Based on the information available and a similar report in the OfficeDev GitHub repository, the Mailbox.SharedFolder permission appears to be the main item worth isolating first. A similar deployment received the same Invalid Resource Specific Permission message after this permission was added to a unified manifest. However, the related report is still under review, so I cannot confirm from the Community whether this is an officially recognized product bug: Unified manifest with Mailbox.SharedFolder permission doesn't show up in Teams · Issue #6757 · Offi…

    As a test, you may temporarily remove Mailbox.SharedFolder from a separate test version of the manifest and then sideload or deploy the test package again. If the deployment succeeds without this permission, that would help confirm that the validation failure is specifically associated with how this permission is being handled.

    You may also consider testing the traditional add-in-only manifest instead of the unified manifest. The add-in-only manifest uses a different permission model for Outlook add-ins and shared mailbox scenarios. Microsoft provides more information about Outlook add-in permissions here: Understanding Outlook add-in permissions - Office Add-ins | Microsoft Learn

    Since the manifest has already passed AppSource validation and the problem occurs during deployment from Integrated Apps, I also recommend opening a support request through the Microsoft 365 Admin Center. A Microsoft Support agent can collect the relevant deployment details and review the behavior with the appropriate product team.

    When submitting the request, please provide the tenant ID, AppSource listing URL, deployment correlation ID, screenshot of the complete error, and the relevant authorization.permissions.resourceSpecific section of the manifest. Please send these details privately through the support request rather than posting tenant information publicly.

    I hope these tests help isolate the permission involved while Microsoft Support reviews the deployment behavior more closely.

    Kind regards,

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.