Skip to main content

Observability

The portal exposes two views into how the product is actually working in your tenant:

The Overview drift banner

Lives at the top of /app. Fires when at least one observed user is running an older sideloaded add-in manifest than what our API is currently serving. Includes a count and a deep link to the sideload page.

The Deployment page

Outlook Add-in card

Shows the sideload URLs and ZIP download. Auto-expands if a newer version is available so you don't miss the update.

Observed Versions card

This is the ground truth — populated by the add-in itself, reporting its version + platform on every API call.

Three signals on the header:

  • All on latest (green) — every observed user is on the current version. No action needed.
  • Drift (amber) — at least one user is on an older manifest. Listed underneath, by user.
  • No data yet (grey) — the add-in is uploaded but nobody has opened it yet.

Distribution table:

VersionUsers
2.2.612Latest
2.2.53

Users table:

UserVersionLast seen
alice@acme.com2.2.6 🖥 🖥💻2 minutes ago
bob@acme.com2.2.5 🌐 drift4 hours ago

The icons next to each version are the Office platforms that user has opened the add-in on (Outlook Windows / Mac / Web / iOS / Android / new Outlook). Hover any icon for the full user-agent + last-seen timestamp.

Why a single user can have two icons

The add-in reports its host per session. A user who uses Outlook on their Mac in the morning and OWA on their iPad in the afternoon shows up as one row in the users table with two icons under their version.

What to do with drift

The most common cause is Outlook caching the old manifest after you upload a new one. Ask the affected users to:

  1. Restart Outlook (closes and re-opens the iframe).
  2. If that doesn't help, remove the add-in from Get Add-ins → My Add-ins and re-add it.

For tenant-wide assignments via M365 admin centre, drift usually clears itself within ~12 hours as Office propagates the new manifest version.