Presence federation: decode degraded sync states

Every provider tile on Settings → Presence reports the outcome of its last sync as a badge, and a small set of underlying status values drives those badges. This page maps the badge you see to the recorded sync status, its cause, and the exact fix. Setup — connecting a provider or opting in — is on the Presence federation guide; this page is the one to open when a tile is degraded.

Badge to status to fix

Tile badge	Recorded sync status	What happened	Fix
Synced	`ok`	The last poll connected and read a presence value.	None.
Waiting for first sync	`null` (no sync recorded yet)	The source is on, but it has not completed its first poll — or none has succeeded yet.	Give it about a minute after you flip the switch. If it never resolves, treat it as a silent authorization failure and follow the Reconnect required row.
Reconnect required	`auth_error`	The provider refused the request for authorization, or the connection that carried the OAuth grant no longer exists. The token was revoked, the consent was never completed, the grant lost a required scope on the provider side, or the org-level connection was disconnected.	An org admin reconnects the matching integration in Settings → Integrations; the tile names which one. Microsoft Teams and Microsoft 365 Calendar both authorize through the Microsoft 365 connection; Google Calendar through Google Workspace. The next sync clears the badge within about a minute.
Retrying	`transient`	The last poll hit a temporary provider or network failure — a rate limit, a 5xx, a timeout — that stayed after the built-in retries.	Nothing. The next poll runs about a minute later, and the badge clears as soon as one succeeds. Escalate only if Retrying persists for hours.
Unrecognised value	`unknown_payload`	The provider answered successfully, but returned an availability value we do not map to a status yet — usually a provider-side rollout introducing new presence labels.	No tenant action resolves it; routing falls back gracefully (below). Escalate so support can map the new value; include the tile’s provider-reported raw value.

What “Reconnect Microsoft 365” means

Reconnect Microsoft 365 is the action the tile suggests when a source that rides the Microsoft 365 grant — Microsoft Teams or Microsoft 365 Calendar — records auth_error. The Microsoft 365 connection your org admin authorized in Settings → Integrations no longer holds a working OAuth grant: the refresh token was revoked at Microsoft (a password change, an admin consent removal, a conditional-access policy change, and app uninstalls all revoke it), the grant expired, or the admin consent step was never completed. The per-user opt-in switch still says ON — the switch records your choice to federate; the badge records that the underlying authorization failed. The fix is always the same:

An owner or admin opens Settings → Integrations.
Open the Microsoft 365 integration and select Reconnect (or Connect, if it was removed outright).
Complete the Microsoft consent screen with an account that can grant the permission.
Back on Settings → Presence, the badge flips to Synced at the next poll — roughly a minute.

Until the reconnection lands, presence sync from Teams and Microsoft 365 Calendar has stopped entirely — tiles show Reconnect required, not a stale-but-quiet state. That means presence has stopped silencing your phone: inbound calls ring as if the source were off, using whatever status you set yourself in the dashboard header. Re-granting consent when the provider removed a scope (the Microsoft 365 consent screen lists the permissions; fewer are granted after an admin edits it) follows the identical path — reconnect once, and the full consent screen re-issues every required permission. It is also the identical path for the other providers: Slack, Webex, and Zoom each get the same Reconnect required badge when their own grant dies, fixed through the integration the tile names. The org-level reconnection covers every member at once — nobody needs to re-toggle their own switch after the grant is back.

What never works — avoid these

Toggling the source off and on for an auth_error. The switch only records your opt-in; it cannot re-issue an OAuth grant. The badge returns on the next poll.
Removing the source for an auth_error. The Remove source control is intentionally hidden while no successful sync exists — there is nothing healthy to remove. Reconnect the integration instead.
Waiting out a token_revoked-class failure. Revocation at the provider is terminal; no poll heals it. Reconnect.
Revoking the org’s own network access — no firewall or proxy change on your side heals anything either way: syncs run from Devotel’s side through the integration service, not from your browser.

Graceful fallback: what routing does while a source is degraded

Presence federation can only make you appear busier — never less busy — and a degraded source stops contributing at all. An auth_error, transient, or unknown_payload source drops out of the merge, so your status falls back to what remains: other healthy sources, and always the status you set yourself in the dashboard header. Routing never treats a broken federation as “unavailable”: while a tile reads Reconnect required or Retrying, calls ring exactly as if that source were off. The catch is that the Busy / Do Not Disturb signal the source was feeding is what you lost — if you relied on Teams or a calendar to silence your phone during meetings, silencing stops until the source recovers. Set Do Not Disturb manually from the dashboard header as an interim; a manual status always wins over federated sources and the recurring schedule.

When to escalate

Escalate to Devotel support when any of these holds:

Reconnect required returns within minutes of a clean reconnection — the grant is revoked again immediately, which usually means a provider- side policy (a Microsoft conditional-access rule, an admin app block) we can identify from the recorded error message on the tile.
Retrying persists for more than a few hours — the provider is having an extended outage we should confirm and track from the platform side.
Unrecognised value — any occurrence. Attach the tile’s provider- reported raw value so we can add the mapping.
Waiting for first sync never resolves across an hour with the org-level integration confirmed Connected — the opt-in row exists but syncs never reach it.
A reconnection completes and the badge still sits on Reconnect required for everyone after several polls.

Include in the ticket: the tile’s provider name, the badge, the “Provider reports” raw value if one is shown, and the time the reconnection completed.

Cross-references

Presence federation settings — provider setup, the busy/away/DnD behavior matrix, and the org-admin vs per-user split.
Troubleshooting hub — every other runbook, grouped by the surface it works on.
Agent presence and aux-code lifecycle — the five-state model dispatch reads before it rings.

​Presence federation: decode degraded sync states

​Badge to status to fix

​What “Reconnect Microsoft 365” means

​What never works — avoid these

​Graceful fallback: what routing does while a source is degraded

​When to escalate

​Cross-references