Teams shows "Available" while Outlook says "Out of Office" because the two apps read different presence sources and resolve conflicts with a fixed priority order. Microsoft Teams computes your presence from your activity state, your calendar's free/busy signal, and any manually set duration. Outlook's automatic replies are a separate mail feature stored on the Exchange mailbox. When the signals disagree, Teams follows its own precedence rules, and "Available" can win.

The presence engine: what Teams actually reads

Presence in Teams is not a single switch. It is a computed value assembled from several inputs that Microsoft calls presence states and presence sources. The client collects an activity signal (keyboard, mouse, calls, meetings), a calendar signal (free, busy, out of office, working elsewhere), and an explicit user-set signal (a duration you choose from the status menu). The service merges these on every refresh, roughly every few minutes for calendar-derived states and near-instantly for local activity.

The conflict you are seeing comes from the fact that the calendar signal and the mail signal are different objects. Outlook's automatic replies are an Exchange mailbox rule that fires when a message arrives. Teams does not read that rule. Teams reads the calendar entry that Outlook writes when you enable automatic replies with the "during this time range" option, which creates an event marked show-as Out of Office on your calendar. If that event is missing, malformed, or outside its window, Teams has nothing to display even though Outlook is replying to every sender.

A second layer is the precedence order. Microsoft documents the ranking as: a manually set duration outranks calendar-derived status, which outranks activity-derived status, which outranks app-level status. So a manual "Available" set for the next four hours will override an Out of Office calendar block. That is the single most common cause of the mismatch, and it is invisible unless you know to look for the duration chip under your profile picture.

Think of it as two clerks reading two different ledgers. Outlook reads the mail ledger. Teams reads the calendar ledger, then checks whether you wrote a note on the front desk.

The precedence order, quantified

The hierarchy matters because each level can suppress the one below it, and each has a different expiry behavior. Activity-derived states such as Available, Busy, and Away refresh continuously and typically revert to Away after about 5 minutes of no input on desktop, with mobile behavior differing by platform and app version. Calendar-derived states hold for the duration of the event, including all-day events, which behave differently from timed events. Manual durations hold exactly as long as you set them, from 30 minutes to several hours depending on the client.

Signal Source Typical refresh Overrides
Manual duration User-set status menu Holds until expiry Calendar, activity, app
Calendar Out of Office Outlook event, show-as OOF Minutes; event-bounded Activity, app
Calendar Busy/In a meeting Outlook event, show-as Busy Minutes; event-bounded Activity, app
Activity state Client input detection Seconds to ~5 min idle App-level only
App-level status Per-app override Real-time Nothing above it

Two thresholds get reconciled here and often confused. The idle-to-Away threshold (roughly 5 minutes on desktop) governs activity states only. The automatic-reply window (the start and end date you set in Outlook) governs whether Outlook replies at all. Neither one directly controls the Teams calendar signal; that is controlled by the calendar event's start and end times, which may not match your automatic-reply window if you set them separately.

A counterintuitive detail: Teams can show Available while you are in a meeting if that meeting's show-as is set to Free or Working Elsewhere. Teams reads the show-as field, not the fact that an event exists. An event marked Free is treated as available time, so a busy calendar full of Free meetings produces an Available presence all day.

Edge cases that break the sync

Several configurations produce a persistent mismatch that survives restarts.

Delegates and shared calendars. If an assistant manages your calendar and sets automatic replies on your behalf, the Out of Office event may be created on the delegate's calendar or with a different organizer, and Teams may not attribute it to you. The presence engine attributes calendar state to the mailbox owner of the event, so a mismatched organizer silently drops the signal.

Multiple mailboxes and hybrid environments. Accounts with both an on-premises Exchange mailbox and a cloud mailbox, or with more than one Exchange account in the Outlook profile, can write the OOF event to a mailbox Teams is not reading. Hybrid coexistence configurations are a documented source of presence and calendar inconsistency.

All-day events. An all-day Out of Office event spans midnight to midnight in the calendar's time zone. If your Teams client and mailbox are in different time zones, the event can appear to start hours late or end hours early, producing a window where Outlook replies but Teams shows Available.

Mobile-only automatic replies. Enabling automatic replies from the Outlook mobile app writes the same mailbox rule but the calendar event creation path differs by client and version, and the reply window and calendar window can diverge.

Red-flag warnings worth checking first: A manual status duration set earlier today, still counting down. An Out of Office event whose show-as is Free or Busy rather than Out of Office. Automatic replies enabled with no date range, so no calendar event was created. Two Exchange accounts in one Outlook profile, with the OOF event on the wrong one. A Teams client signed into a different tenant than the mailbox.

The professional caveat: presence is advisory, not a guarantee of availability or responsiveness. Do not build escalation logic or SLA monitoring on presence state alone, because precedence rules and client refresh timing make it an unreliable signal at the minute level.

Misconceptions: what presence is not

The most durable misconception is that Outlook's automatic replies and Teams presence are one feature. They are not. Automatic replies are a server-side mail rule. Presence is a computed service state. They share a calendar event as a bridge, and the bridge is optional depending on how you enabled the replies. This is why the two can disagree indefinitely without either one being broken.

A second misconception is that "Available" means you are at your desk. It means no higher-priority signal is currently suppressing it. If your calendar has no Out of Office event and you set a manual Available, the engine has no reason to show anything else, even if you are on a plane.

A third is that fixing presence requires an IT ticket. Most mismatches resolve from the user's own status menu or by correcting the calendar event's show-as field. Escalation is appropriate only when the calendar event is correct and presence still disagrees after a client restart and a sign-out, which points to mailbox or tenant configuration.

A fourth is that the mobile app and desktop app always agree. They read the same service state but cache it differently, so a stale mobile client can display an old status for minutes after the desktop has updated. If you are diagnosing, compare both clients before concluding the service is wrong.

Practical actions: forcing the states to agree

Work through these in order, because the cheap fixes resolve most cases.

First, check your manual status. Open your profile picture menu in Teams, look for a duration chip such as "Available until 4:00 PM," and clear it. A leftover manual duration is the top cause of the mismatch and takes five seconds to rule out.

Second, verify the calendar event. Open Outlook's calendar, find the Out of Office event, and confirm three things: show-as is Out of Office, the start and end times cover now, and the organizer is your own mailbox. If any of those is wrong, edit the event or delete it and re-enable automatic replies with a date range so Outlook recreates it.

Third, re-enable automatic replies correctly. Turn automatic replies off, save, turn them back on with an explicit start and end date and time, and save again. This forces a fresh calendar event. Allow a few minutes for the presence service to pick it up.

Fourth, restart and re-authenticate. Sign out of Teams, quit fully including the background process, sign back in, and confirm the correct account and tenant. This clears cached presence state and resolves most multi-account attribution errors.

Fifth, check for duplicate accounts. In Outlook, review File, Account Settings, and confirm only the intended mailbox holds the Out of Office event. Remove or deprioritize the extra account if one exists.

Sixth, escalate with evidence. If all five steps fail, capture a screenshot of the calendar event's show-as and time range, the Teams status, and the Outlook automatic-reply settings, and send them to your IT administrator. That evidence distinguishes a client bug from a mailbox configuration problem and saves a round trip.

For recurring mismatches, a practical threshold is two occurrences in a month. Below that, treat it as a client cache artifact. Above that, ask IT to verify the mailbox's calendar processing settings and whether your account sits in a hybrid configuration.

Limits: what this explanation cannot cover

Presence behavior varies by Teams client version, by licensing tier, and by whether your organization uses a cloud-only or hybrid Exchange topology. Microsoft updates presence precedence and calendar integration periodically, so any specific refresh interval or menu label can differ from what you see. The precedence order described here reflects documented behavior, but tenant-level policy can add or remove signals.

The article also cannot tell you whether a specific mismatch is caused by your configuration or by a service incident. That requires checking your tenant's service health dashboard and your own client logs. And no presence state is a reliable indicator of whether a person has read a message or will respond, because reading and responding are separate signals from presence, with their own delivery and timing behavior.

If you are diagnosing on behalf of someone else, remember that you may be seeing a cached view. Presence shown to a colleague can lag the state the person sees on their own client, so confirm with the account holder before concluding anything about their settings.

This article is general educational information about how calendar and presence integration works, not a diagnosis of your specific configuration or a substitute for guidance from your organization's IT administrators. Configuration options, menu labels, and refresh behavior change across client versions and tenant policies, so verify details against your own environment or a qualified support professional before acting.