Front Shared Inboxes & Team Inboxes Explained

The three shapes of an inbox

Front has one core object — a conversation — and several containers for it. The container decides visibility.

An individual inbox is your personal space. Per Front's documentation on individual inboxes, you add one under gear icon → Personal settings → Inboxes → Create individual inbox, and by default it is not visible to teammates. It's where your own connected email lives, split into the familiar Open / Snoozed / Done conversation states rather than a permanent folder tree. A teammate can connect up to ten individual channels to their account.

A shared inbox is the team container — the thing most people mean when they say "Front inbox." It's described in Front's shared inbox help article as an organizational space where you categorize or sort conversations, and it can hold channels (email like support@, plus SMS, Instagram, and more) or sit empty as a routing destination. Everyone with access sees the same conversations, the same comments, and the same real-time state. If you want the conceptual deep-dive on that model, we cover it in Front shared inbox explained; this post is about how several of those inboxes get structured and permissioned together.

A team inbox isn't a separate object type — it's simply a shared inbox scoped to a team, usually via restricted access and teammate groups (more on both below). So "team inbox" is really a permissions pattern layered on top of the shared-inbox primitive, not a fourth kind of container.

How access works: Public vs Restricted

When you create a shared inbox — Settings (gear) → select your workspace → Inboxes → Create shared inbox — you name it, give it a color, and hit the Access setting. This is the decision that defines who's on the team. Front gives you two modes:

• Public — "Grant access to all teammates in the workspace." Every teammate in that workspace can see and work the inbox. Front's make inboxes public guidance notes public inboxes are selected by default for teammates and can't be deselected, which is exactly what you want for a genuinely shared support@ queue.
• Restricted — "Grant access to specific teammates or teammate groups." This is how you build a true team inbox: a VIP escalations queue, a finance inbox, or a region-specific desk that only its members should see.

The creation flow also includes a sidebar visibility step (which teammates get the inbox pinned in their sidebar automatically) and a Ticketing toggle that's on by default. Access and sidebar visibility are separate concepts, which trips people up — having access doesn't guarantee the inbox shows in your sidebar.

Teammate groups: membership at scale

Adding people one by one to every restricted inbox doesn't scale past a handful of teammates. That's what teammate groups are for. Per Front's managing inbox access with teammate groups documentation, an admin goes to Company settings → Teammate groups → select a group → Access and permissions → Access column and toggles on the inboxes that group should reach. From then on, "every member of that group will be able to view the inbox and its contents" — add a new hire to the group and their access follows automatically.

Two behaviors are worth memorizing because they cause the most "why can't I see this?" tickets:

1. Access is additive. A teammate can be granted an inbox through a group and individually and through workspace access. Removing them from one path doesn't necessarily remove access if another path still grants it.
2. Access doesn't mean it's on your sidebar. Front notes that even after a group is granted access, "the inboxes will not be displayed on the users' sidebars by default" — each person still chooses which of their accessible inboxes to pin. Access and visibility are decoupled on purpose.

Teammate groups are available on all Front plans, and they double as a targeting mechanism inside Front rules — the same group you use for access can be the assignee in an automated routing rule.

Assignment scope: where a conversation actually "lives"

Access decides who can work an inbox; assignment decides who should work a given conversation. In Front, a conversation sits in one or more inboxes, and you assign it to a single teammate to make ownership unambiguous. Assignment doesn't move the conversation out of the shared inbox — everyone with access still sees it — it just stamps a clear owner so the rest of the team knows to leave it alone. This is the sales/ops-friendly middle ground between a free-for-all and rigid ticket queues: the conversation stays visible to the team, but responsibility is explicit.

A related pattern is the delegated inbox. Front's inbox delegation feature lets you grant a teammate the ability to view and act inside your individual inbox — archiving, snoozing, replying — which is how an EA covers an exec's mailbox or a teammate covers PTO without the mailbox becoming fully shared.

Collision avoidance: the shared-inbox superpower

The whole reason shared inboxes beat forwarding email around is that Front stops two people from doing the same work twice. Its real-time collision detection shows you, inside a shared inbox, when "a teammate is working on a message" — you see indicators that they're replying, and draft content is shared and updated in real time. Combined with per-conversation assignment and internal comments / @mentions (a genuinely Front-native way to loop in a colleague without CC-ing the customer), the result is that a busy support@ inbox with ten agents rarely produces duplicate or contradictory replies. That comment-and-presence layer, not the folder structure, is what makes Front feel collaborative rather than just "email with more people."

The honest limits — and where an AI layer fits

Front's inbox model is well-designed for what it is: a clear, human permission system. But it's worth being straight about its edges.

It's a visibility model, not a workload model. Access controls who can see an inbox; it doesn't reason about who should take the next conversation based on skills, current load, or language. Assignment is still a manual (or rule-based) act, and rules match on fixed conditions — they don't understand intent.

Structure can sprawl. Restricted inboxes plus overlapping teammate groups plus additive access is powerful, but it drifts. Six months in, most teams have at least one inbox where nobody's quite sure why a given person still has access. Front gives you the levers; it doesn't audit them for you.

And it doesn't write the reply. A shared inbox routes a conversation to the right team and prevents collisions — but a human still has to read the message, understand the ask, and draft the answer. When the question is "where's my order #4471?", the inbox can't fetch that; it just holds the conversation while a teammate goes and looks.

That last seam is where an AI agent layer earns its place, and it's worth weighing the build-versus-buy tradeoff before adopting one. The broader category of AI agents for customer service exists to do the reasoning-heavy work an access model can't. Macha is one such layer: it runs on top of the Front you already use via a live native connector — it does not replace Front, its inboxes, or its permissions. Once connected to Front, Macha reads and writes the same shared conversations your team already works: drafting grounded replies inside a shared inbox, triaging by intent so a conversation reaches the right teammate group, and looking up order or account status through a custom tool that turns a REST API into something an agent can call. Credits are consumed per AI action, not per resolution — the pricing page has the full breakdown, and if you're budgeting Front itself, our Front pricing explained post covers the plan tiers.

The clean division of labor: keep Front's inboxes, groups, and assignment as the source of truth for who can see what and who owns what, and layer an agent on top for the part the permission model can't do — actually answering fast enough that the queue never backs up. Tagging conventions help here too; we cover those in Front tags explained.

FAQ

What's the difference between a shared inbox and a team inbox in Front? There's no separate "team inbox" object — a team inbox is just a shared inbox with Restricted access, so only specific teammates or teammate groups can see it. A plain shared inbox can be Public (everyone in the workspace) or Restricted; "team inbox" is simply the restricted pattern applied to a team.

How do I control who can access a Front inbox? When you create or edit a shared inbox (Settings → workspace → Inboxes), open the Access setting and choose Public (all teammates in the workspace) or Restricted (specific teammates or teammate groups). For scale, grant access through teammate groups under Company settings → Teammate groups → Access and permissions.

Why can a teammate access an inbox but not see it in their sidebar? Access and sidebar visibility are separate in Front. Even after a group is granted access, inboxes aren't pinned to members' sidebars by default — each person chooses which accessible inboxes to show. So a teammate can have full access while the inbox stays hidden from their sidebar until they add it.

Does Front prevent two agents replying to the same conversation? Yes. Front's real-time collision detection shows indicators inside a shared inbox when a teammate is already working on a message, and per-conversation assignment plus internal comments make ownership explicit — so duplicate replies are rare even in a busy support@ queue.

Can I add AI to Front inboxes without replacing Front? Yes. An AI agent layer like Macha connects to Front through a native connector and runs on top of your existing inboxes, groups, and assignment rules — it doesn't replace them. It helps by drafting grounded replies inside shared inboxes and routing conversations by intent, while Front stays the system of record for access and ownership.

Ready to help your team move the queue instead of just organizing it? Start a free trial of Macha and connect it to your Front in minutes.