Teams status keeps changing in Outlook — quick diagnosis

Your Teams presence shown in Outlook changes because an authoritative client or service writes a presence value to Microsoft’s presence service and Outlook displays whatever value it receives most recently. Common writers are signed-in Teams clients (desktop, web, mobile), your Exchange calendar, or a tenant/server-side policy; fixing this means isolating which actor is writing presence and either stopping or changing that actor. The steps below let you reproduce the flip with minimal variables, run quick checks, collect the logs IT will need, and apply safe short-term or permanent fixes.

Symptom (what you see and when it happens)

You see your presence badge or status text in Outlook change without you setting it. Typical observations:

• Status flips to Busy or In a meeting at meeting start times, even if you didn’t join.

• Status toggles between Available, Away, or Do not disturb while you’re actively working on your desktop.

• Status changes when you use your phone, a browser, or a second PC, or after background apps run.

• The flip doesn’t match any visible action you took and occurs outside scheduled meetings.

If there is a literal error message from a client, capture it. Otherwise note exact times, which devices were signed in, and whether a calendar event was active when the change happened.

Before you start (scope, permissions, safe checks)

This guide applies to Microsoft 365 users whose Outlook shows Teams presence (Exchange Online + Teams integration). You do not need admin rights to run the local checks, but tenant-level policy changes require an admin.

• Prerequisites

• You must be signed into your work account in the clients you test.

• Have access to Outlook and at least one device with Teams (desktop or web).

• Safe checks and warnings

• Do not ask IT to perform tenant-wide sign-outs or profile deletions without approval.

• Back up any custom Outlook profiles or rules before you change them.

• When collecting logs, redact other users’ PII if you share files outside IT.

Stopping condition: if a check identifies a single client as the cause and the fix in this article resolves it, you can stop. If tests point to server-side policy or a bot, gather the escalation packet and involve IT.

How Teams presence reaches Outlook (brief technical flow)

Presence is stored in Microsoft’s presence service and multiple clients or services can write it. Outlook reads presence from that service via presence APIs and shows the latest value.

• Common writers

• Teams desktop and web clients: send presence updates based on activity and manual status.

• Mobile Teams app: often writes more recent timestamps because it’s frequently online.

• Exchange calendar: events with Show As Busy / In a meeting can set presence for the event period.

• Server-side: presence policies, Conditional Access/Intune-triggered sign-outs, Graph-based integrations, and third-party connectors or bot accounts can also write presence.

What overrides what

• The presence value with the newest write timestamp is what Outlook displays. Calendar-derived presence for an active meeting typically overrides a manual status while the meeting runs.

Prioritized triage — quick checks to isolate the writer

Run these checks in order. Each check takes 1–5 minutes.

1. Reproduce with one client only

1. Sign out or quit Teams on every device: desktop, browser tabs, and mobile.

2. Start only the Teams desktop client and wait 30–60 seconds. Check Outlook presence.

Expected: if the desktop client is the source, the flip will occur now. If not, continue.

2. Test the Teams web client separately

1. Sign out of desktop Teams and open a Private/Incognito window.

2. Sign in to https://teams.microsoft.com and wait 30–60 seconds. Check Outlook presence.

Expected: if presence changes with web only, the issue is client-side.

3. Test mobile separately

1. Sign out the web and desktop clients.

2. Sign in only on the Teams mobile app, or force-sign out of it, then observe Outlook.

Expected: if signing out mobile stops flips, the mobile app was sending updates.

4. Check calendar timing with a test meeting

1. Create a 5–10 minute calendar event titled "test presence" with Show As Busy.

2. Observe whether your Outlook status switches to Busy/In a meeting when the event starts.

Expected: if status matches the event, calendar-derived presence is working as expected.

5. Close background presence writers

• Quit Skype for Business, softphones, other collaboration apps, and Outlook background processes.

• On Windows use Task Manager to confirm there isn’t a second Teams process.

Expected: if flips stop, a background app was the source.

What each result implies

• Only one client reproduces the flip: fix that client (reinstall or reset cache).

• Status matches calendar events: calendar-derived presence is the cause; check event Show As, organizer/delegate settings, and connectors.

• Flips with no active client: likely server-side (policy, bot, or Graph integration); collect logs and escalate to IT.

Targeted fixes (ordered steps), what to expect, and recovery

Apply the safe, reversible fixes below in order from least intrusive to more involved. Stop when the flip stops.

1. Sign out other devices and confirm single-client behavior

1. Sign out or quit Teams on all other devices (desktop, browser, mobile).

2. Keep only the suspected client signed in and observe for 10–15 minutes.

Expected: if flips stop, keep the other devices signed out until you update or reinstall the problematic client.

2. Clear Teams desktop cache

1. Quit Teams completely.

2. Delete cache folders below and restart Teams.

%appdata%\Microsoft\Teams

Expected: resolved if client cache caused stale writes. If unchanged, restore any backed-up settings and continue.

3. Run Outlook in Safe Mode to test add-ins

1. Close Outlook.

2. Start Outlook in Safe Mode.

outlook.exe /safe

Expected: if flips stop, an Outlook add-in/connector is writing presence; disable add-ins one by one in normal mode to find the culprit.

4. Test calendar-derived presence locally

1. Edit a test event and change Show As to Free, then observe whether presence remains Available during the event.

Expected: if changing Show As to Free prevents the meeting status, calendar-derived presence is active. If you need permanent change for all events, ask IT to change tenant policy.

5. Check and sign out suspicious background apps

1. Quit Skype for Business, softphone apps, and any third-party calendar connectors.

Expected: if flips stop, that app was writing presence. Uninstall or reconfigure it.

6. If you’re an admin: review tenant presence policies and Graph integrations

1. In the Teams admin center, check presence policies assigned to the user.

2. Review Conditional Access/Intune sign-out activity and service principals that can write presence via Graph.

Expected: if a policy or integration wrote presence, change the policy, or remove/modify the integration. If you need Microsoft support, gather the logs below first.

Logs, traces and the escalation packet for IT or Microsoft

Collect these items before contacting IT or Microsoft support.

• What to capture locally

• Screenshot of Outlook presence badge and any tooltip showing the status.

• Screenshot or export of the calendar event (time, Show As, organizer, attendees).

• A short timeline of your steps with exact timestamps (e.g., "09:04 signed out phone", "09:07 cleared cache", "09:08 flip observed").

• Teams desktop logs

1. Use the Teams feedback menu -> collect logs, or run Teams with the collect flag.

%appdata%\Microsoft\Teams\current\Teams.exe --collect-logs

2. Note the logs path: %appdata%\Microsoft\Teams\logs.txt and the diag* folders.

• Outlook logs

1. Enable MAPI logging in Outlook (File -> Options -> Advanced -> Enable troubleshooting logging), reproduce the flip, then stop logging and save the files.

• Graph/tenant traces (for IT)

• Ask IT to run presence queries via Microsoft Graph for your user to see presence write timestamps and client IDs.

• Ask IT to check audit logs for Conditional Access/Intune sign-outs, and Teams admin center presence policy assignments.

Escalation packet (copy-paste)

Subject: Teams presence flipping in Outlook — requested diagnostics
User: <your UPN/email>
Observed behaviour: presence changes to <state> at <time> without my action; occurs when <describe conditions>
Steps already tried: signed out all devices at <time>, ran Teams web only at <time>, cleared Teams cache at <time>, ran Outlook in Safe Mode at <time>
Attached logs: Teams logs (path and filename), Outlook MAPI logs (path and filename), screenshots of calendar event and Outlook badge
Repro steps: 1) Ensure only desktop Teams signed in; 2) Observe presence switching at <time> or after action <action>
Request: Please check presence policy for my account, Graph presence write events for my account (timestamps and client IDs), and recent Conditional Access/Intune sign-out events.

Verify (how to confirm the fix worked)

Run these verification steps after a suspected fix.

1. Single-client stability test

1. Sign out all other devices.

2. Keep the fixed client signed in and observe presence for 10–15 minutes while you work.

Expected: presence remains stable and reflects your activity.

2. Test with a controlled meeting

1. Create a 5–10 minute test meeting with Show As Busy.

2. Observe whether presence changes only when you want it to.

Expected: if calendar-derived presence is intended, the status should change only for the meeting period. If it still flips unexpectedly, collect logs and escalate.

3. If an admin changed a policy

1. Ask the admin to provide the Graph presence write log showing the policy or service principal write timestamp.

Expected: the admin-provided log should match your observed flip timestamps.

Prevent (practical steps to reduce future flips)

Short, practical things you can do to lower the chance of surprise status changes.

• Sign out unused devices, especially mobile, when you need stable desktop presence.

• Avoid third-party calendar connectors or add-ins that write presence; test add-ins in a controlled profile before enabling in normal use.

• For admins: use presence policies sparingly and document any Graph apps that have presence-write permissions.

• Keep Teams clients up to date; version details can change, so verify current guidance in Microsoft 365 admin documentation before making tenant-wide changes.

Conclusion

If local tests point to a client or calendar event, the safe fixes above usually stop flips quickly. If logs show a server-side write or a third-party integration, send the escalation packet and artifacts to IT so they can run Graph presence queries and review admin logs. If you’re an admin and need help interpreting presence timestamps, gather the Teams logs, Outlook MAPI logs, and Graph presence history before you open a Microsoft support case.