Front Emails "Reopening" (Reopened in Office 365 Inbox): How to Fix

Symptom → likely cause, at a glance

Start here to point yourself at the right section.

Cause 1 — "Close conversations" lets new messages reopen threads (most common)

This is the default behaviour, not a bug. By design, an archived Front conversation is closed, not deleted — and when a new inbound message arrives on that thread, Front reopens it so nobody misses a customer's follow-up. That's usually what you want in a shared inbox. It becomes a problem when your channel's Close conversations setting is configured so that any new activity resurfaces old threads you considered done.

You control this on the channel itself. As the caption below notes, this is the exact settings surface where reopening is governed.

Notice Front's own inline warning: setting Close conversations to Never means new inbound messages will reopen threads. The fix:

1. Open the Settings gear → Channels, pick the affected channel (your Office 365 or Gmail inbox), and open the Settings tab.
2. Find Close conversations and read the warning. If it's on Never, that's why replies keep reopening old threads.
3. Choose a policy that matches how your team works — closing conversations on your terms rather than leaving every thread eligible to spring back.
4. Save. Changes govern behaviour going forward, so you may still need to re-archive the batch that already reopened.

If you're new to how archiving and reopening fit the wider model, Front's shared inbox explained covers the open/closed lifecycle, and Front channels explained covers where these per-channel settings live.

Cause 2 — A sync-breaking action moved the conversation

Front keeps a two-way sync with Office 365, but only for a narrow set of actions — and some things you do quietly break it. Per Front's list of actions that break the sync between Front and Gmail/Office 365, the sync is severed when you move a conversation to a different inbox than where it arrived, reply from a different account than the original, change the threading mode, or split/merge conversations (whether by smart merge or manually). Once the link is broken, a later reply can surface as a reopened or duplicated thread because the two systems no longer agree on what state the conversation is in.

The single most important rule Front gives is blunt: "You should not have the same account open in Gmail/Office 365 and in Front." If a teammate is also working the mailbox directly in Outlook or Outlook Web, their archive/read/move actions there can race against Front's and manifest as reopenings.

Fix steps:

1. Audit who touches the mailbox. Make Front the single front-end for that inbox and have the team stop working it directly in Outlook/OWA.
2. When routing, avoid moving conversations across inboxes mid-thread where you can; route at intake instead. Front rules can assign and tag without physically relocating a conversation after replies exist.
3. If replies must go out from a specific address, confirm you're replying from the same account the message arrived on.

Cause 3 — Threading mode is fighting the provider

When you connect Office 365, Front defaults to "Office 365 threading" — and switching that off stops the O365 sync. Per Front's guide to email threading and how to change your threading mode, the Office 365 default threads messages by Office 365's own logic plus regular email threading. If you change threading to a Front-native mode (or Subject-Recipient), Front warns that you'll keep the inbound/outbound sync but lose spam-status sync — and, more importantly, altering threading is itself one of the sync-breaking actions from Cause 2. A mismatch here shows up as replies threading oddly, re-splitting, or old conversations resurfacing when the two systems reconcile.

To inspect or change it safely:

1. Settings gear → Channels → pick the channel → Settings tab → Threading mode.
2. For an Office 365 channel that must keep two-way sync intact, leave it on Office 365 threading — that's the mode designed to co-operate with the provider.
3. If you do change it, know two things: the change applies only to new conversations going forward, and you've now broken the tight O365 sync for that channel by design. Use manual split/merge for existing threads rather than expecting a mode change to retro-fix them.

Honest note: threading mode is a per-channel setting on a connected email channel. If you're on a Front trial without a real Office 365 or Gmail channel connected, you won't see the O365-specific options at all — this cause only exists once a live provider is attached. Connecting Gmail to Front walks the equivalent setup on the Gmail side.

Cause 4 — Something outside Front is rewriting the mailbox (the "thousands at once" case)

If old emails reopen in bulk — hundreds or thousands overnight — the trigger is almost always an external change to the Office 365 mailbox, not a click inside Front. In the Front community thread Old Email suddenly showing up, affected teams traced mass "Reopened in Office 365 Inbox" events to a third-party application used to back up Office 365 mail that was touching messages in the mailbox, as well as to data retention policies rewriting mail. Because Front's legacy two-way sync watches the mailbox for new activity, a backup or archiving tool that re-touches thousands of old messages looks, to Front, like thousands of new arrivals — so they reopen.

Fix steps, in order:

1. Find the external actor. Check for O365/Exchange backup or archiving apps, journaling, and retention/compliance policies that modify or re-stamp messages. Pause or reconfigure the tool that's re-touching old mail.
2. Move to Front's newer sync experience. Front's recommended fix in that thread is to migrate off the legacy two-way sync to the newer sync, which — per Front's Office 365 history import and sync — only syncs new messages, sent emails, and spam status, and deliberately does not sync read/unread, archived/unarchived, tag, trash, or snooze actions. Because it stops mirroring archive/read state, an external mailbox tool can no longer force reopenings through those actions.
3. Weigh the trade-off honestly. In the same thread, a user pushed back that the newer sync "does not sync read/unread," which some teams rely on. So this fix trades reopening-immunity for a looser two-way mirror. It's the right call when reopenings are the bigger pain, but go in knowing what you give up.
4. Clear the backlog. After the underlying cause is stopped, re-archive the batch that reopened. New arrivals won't drag them back once the external actor and sync mode are settled.

Migration between sync experiences is an account-level change and can involve a history re-import (Front imports up to 50,000 recent messages, which can take up to 72 hours). Coordinate it with Front support rather than flipping it mid-shift.

Cause 5 — Emails reappearing as archived, not open

If threads resurface already archived rather than reopened, that's expected sync behaviour. Per Front's O365 sync documentation, emails sent or changed outside Front after the account is connected sync back into Front as archived. That's not a reopening at all — it's Front recording an external action without dragging the conversation to the top of your open queue. No fix needed; it's the system working as intended. It only becomes noise if you're scanning "all" views, in which case tightening what you look at (open vs. all) makes it disappear.

Where an AI layer quietly reduces the blast radius

None of the above requires AI to fix — they're settings and sync hygiene, and Front's own controls handle them. But there's a second-order cost to reopening problems that tooling can soften: every resurfaced thread is a conversation a human has to re-read to decide whether it's genuinely open again or just a ghost, and that re-reading is where the time goes when hundreds reopen at once.

That's the seam an AI agent layer fits into. The broader category of AI agents for customer service exists to do the reading and drafting a human would otherwise repeat. Macha is one such layer: it runs on top of the Front you already use through the Macha–Front connector — it doesn't replace Front, your inboxes, or your sync settings, and it won't stop a backup app from reopening mail (that's still a settings fix). What it does is triage the aftermath: when a conversation reopens, the agent reads the full thread, understands whether the new message actually needs a reply, and drafts or sends a grounded one — pulling live order or account context through a custom tool that turns your API into something the agent can call. A reopened thread becomes a few seconds of review instead of a cold re-read. Macha's credits are consumed per AI action, never per resolution, so a quiet reopening it correctly ignores doesn't cost you.

FAQ

Why do my Front emails keep reopening? Most often because the channel's Close conversations setting lets new inbound messages reopen archived threads — that's Front's default, so a customer's reply resurfaces the conversation on purpose. If reopenings come in bulk (hundreds at once), the cause is usually external: a third-party Office 365 backup app or a retention policy re-touching old mail, which the legacy sync reads as new activity.

What does "Reopened in Office 365 Inbox" mean? It's Front telling you a conversation was reopened because of activity detected on the connected Office 365 mailbox — either a genuine new reply, or an external tool/action that Front's two-way sync interpreted as new activity on that thread.

How do I stop old archived emails from reappearing in bulk? Identify and pause the external actor (backup/archiving app or retention policy) rewriting the O365 mailbox, then migrate to Front's newer sync experience, which stops mirroring read/archive/tag actions and only syncs new messages, sent emails, and spam status. Then re-archive the reopened batch.

Does changing my threading mode fix reopening? Not directly, and it can make things worse. On Office 365, changing away from the default "Office 365 threading" is itself a sync-breaking action and applies only to new conversations. Keep Office 365 channels on Office 365 threading if you want the two-way sync intact.

Can I add AI to Front without changing my sync settings? Yes. An AI layer like Macha connects to Front as a connector on top of your existing inboxes and settings — it doesn't touch threading or O365 sync. It reads and drafts replies on the conversations Front surfaces, which reduces the manual re-reading a wave of reopenings creates.

Tired of re-reading resurfaced threads to figure out what's still open? Start a free trial of Macha and connect it to your Front in minutes.