Regression in M365 Integrated Apps: "403 Forbidden" for original manifest and "FormType missing" for modified versions

Hi Tietze, Benjamin,

Thank you for posting your question in the Microsoft Q&A forum. Your detailed explanation and testing methodology are much appreciated.

Since this is a public platform, I’ve moved the Manifest file link to a private message to avoid exposing any personal or organizational information. Please refer to the private message for those details.

Based on your description and a review of recent community feedback, I have seen multiple users report very similar validation conflicts when centrally deploying established Outlook manifests recently.

The fact that the exact same manifest successfully sideloads via OWA (Upload from file) strongly indicates that your XML structure remains valid, and the validation inconsistency appears tied specifically to the Centralized Deployment ingestion pipeline.

However, I regret to inform you that this is a user-to-user support forum. Moderators, contributors, and external Microsoft employees participating here do not have access to backend systems or the ability to intervene directly in Microsoft product features. Our role is limited to offering technical guidance and sharing best practices based on reported issues, requests, or ideas.

For issues of this nature that point toward server-side validation logic anomalies, it is highly recommended to escalate this directly to the engineering team. Please submit a support ticket via the Microsoft 365 Admin Center, and include your GitHub manifest link so their engineers can investigate the deploy pipeline logic directly.

Before doing so, or while waiting for a response from the support team, here are two alternative deployment workarounds you can try right now that might route through different validation endpoints and temporarily bypass the issue:

Workaround 1: Use the dedicated Centralized Deployment Cmdlet
You mentioned using New-App -FileData. Try using the modern cmdlet specifically designed for M365 Centralized Deployment, which might handle validation differently:

New-OrganizationAddIn -ManifestPath "C:\path\to\your\manifest.v4.xml" -Locale "en-US"

Workaround 2: Use the Legacy Add-ins Portal instead of "Integrated Apps"
Since reports suggest this is tied to the modern "Integrated Apps" deployment wizard, try uploading it via the classic Add-ins deployment page. Though they are in the same admin center, they often use distinct validation logic:

1. Go directly to the legacy Add-ins page in the M365 Admin Center. 
2. Click Deploy Add-in and proceed with the upload.

I hope this helps.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

The behavior described can be split into two separate areas: manifest validity and deployment/upgrade behavior in the Microsoft 365 admin center.

From the available information, only the following points are supported:

1. For Outlook add-ins that use the add-in only manifest (XML, schema 1.1), the following are required for mail add-ins:
   • Rule (in RuleCollection / MailApp)
   • Requirements / Sets
   • Form / FormSettings
   • Hosts These are documented as required elements for Outlook (Mail) add-ins in the add-in-only manifest schema.
2. Whenever any change is made to an add-in manifest (including XML-only manifests), the Version element must be incremented. This is required for:
   • Overwriting an existing deployment.
   • Ensuring that updated manifests are recognized and rolled out.
3. When an add-in is deployed centrally (Integrated Apps / Centralized Deployment), some manifest changes require admin re-consent before users can move to the new version. These include:
   • Changes to requested permissions.
   • Additional or changed Scopes (for add-in-only manifests).
   • Additional or changed event-based activation Events. Until consent is granted, users remain on the existing version.
4. For line-of-business (LOB) add-ins deployed via the admin center:
   • The admin must upload the new manifest file to deploy metadata changes.
   • The update is picked up the next time users start the relevant Office application.
5. For Microsoft Marketplace add-ins:
   • When the developer updates the manifest in Marketplace and it is approved, admins do not need to take action; users get the updated manifest automatically.
6. If an add-in “won’t upgrade” or shows upgrade-related warnings, the documented guidance is:
   • Ensure the manifest version is incremented (Version element for add-in-only manifests, version property for unified manifests).
   • Be aware that changes to permissions, scopes, or events will require admin consent again.
7. For Marketplace submissions and validation:
   • The manifest schema version for Office add-ins using the add-in-only manifest must be 1.1.
   • The app version must follow the a.b.c.d pattern and match between the submission form and the manifest.
   • The SupportUrl (for add-in-only manifests) or developer.websiteUrl (for unified manifests) must be valid and public.

The context does not provide details about:

• 403 Forbidden errors when uploading manifests via Integrated Apps or New-App -FileData.
• Any requirement or behavior change around a FormType attribute on Rule elements in the 1.1 schema.
• Any recent regressions or service-side changes in the Microsoft 365 admin center that would cause the specific validation conflict described.

Based on the available documentation, the only actionable, supported steps are:

1. Confirm that the manifest conforms to the add-in-only schema 1.1 and includes all required elements for Outlook mail add-ins (Rule, Requirements/Sets, Form/FormSettings, Hosts).
2. Ensure that every time the manifest is modified (including simplified variants), the Version element is incremented.
3. If permissions, scopes, or events were changed between versions, ensure that the admin performing the deployment has granted consent to the updated manifest.
4. If the add-in is distributed via Microsoft Marketplace, verify that:
   • The manifest schema version is 1.1.
   • The version number syntax and value match between the manifest and the Marketplace submission.
   • The SupportUrl/developer.websiteUrl is valid and public.

For the specific 403 Forbidden and FormType validation conflict, the context does not contain any additional, authoritative explanation or known regression.

References:

• Office Add-ins with the add-in only manifest
• Troubleshoot user errors with Office Add-ins
• Deploy Office Add-ins in the Microsoft 365 admin center
• Deploy and publish Office Add-ins
• Microsoft Marketplace submission FAQ