Understand Office add-in deployment and sign-in
Verify Word and Outlook manifests, HTTPS URLs, authentication, and tenant policies.
In this article
Items to verify
- Use the production Word or Outlook manifest matching the deployed host.
- Confirm that pane, command, icon, and application-domain locations use approved HTTPS URLs.
- Verify WebApplicationInfo and the authorized app registration without copying any secret into a ticket or public documentation.
- Verify Office manifest permissions and tenant policies before assigning users.
- Deploy to a pilot group first, then verify pane opening and sign-in in the real client.
Sign-in path
The add-in attempts to obtain a token for Alaec.Office.Api through supported Office authentication and its configured fallback. The token must target the expected audience; it must never be displayed, logged, or sent outside the add-in boundary.
Practical guidance
Installation, authentication and feature readiness must be checked separately. Use the approved manifest for the intended host and environment, then verify pane loading and sign-in with a pilot user in the actual Office client. A manifest accepted by administration does not prove that every document or email operation is supported.
Advanced tips
Keep a release-specific record of the manifest, client, sign-in outcome and tested feature. If authentication fails, inspect the configured audience and approved environment through administrator tooling without collecting tokens or exposing them in support reports.