Front Teammates, Teams & Permissions Explained (2026)

Teammates and seats: the billing you can't skip

A teammate is a user; a seat is what you pay for. In Front's model, per Front's plans and pricing documentation, a seat is a paid Front license that can be granted to one unique user in your organization. You invite a teammate under Settings → Teammates → Invite, and the moment you add them Front charges a prorated amount covering the time between when they were added and your next billing statement. Plans are assigned at the organization level, and you add or remove seats within a single plan as your team grows or shrinks.

Front is priced per seat, per month, and that's the number to keep an eye on. There's a one-license minimum on the Starter and Professional plans, while Enterprise is arranged directly with Front's sales team. Because billing is per seat rather than per inbox or per conversation, the cost lever is simply headcount — every person who logs in needs a license. For the current tier breakdown and what each plan unlocks, Front's pricing page is the source of truth; we don't quote live numbers here because Front adjusts them.

When you invite a new teammate you can do more than hand them a login. Front lets you add them to teammate groups, clone settings from an existing teammate to save setup, mark them as a company admin, and choose their role for each workspace — no access, admin, member, or a custom role. That per-workspace role choice is where access control really begins.

Roles: member, admin, and custom

Front ships with a small set of default roles and layers custom ones on top. The two you'll use constantly are member and workspace admin, with company admin sitting above them for organization-wide control. A member does the day-to-day work in the inboxes they can reach; a workspace admin manages the inboxes, rules, and settings inside a workspace; a company admin controls settings across the whole account, including who else becomes an admin.

For most teams those three roles are plenty. But the moment you want something in between — say, a teammate who can read and comment in a shared inbox but is not allowed to send outbound replies to customers — you need finer control than member-or-admin. That's what custom roles provide, and per Front's custom roles and permissions guide they let an admin define a tailored set of permissions rather than accepting the all-or-nothing defaults.

Custom roles expose a long list of per-action permissions you can switch on or off, grouped by area. On the conversation side alone you can control:

1. Messages – send (shared channels only) — whether the person can send outbound replies at all
2. Comment – send — internal-only commenting, separate from customer-facing messages
3. Conversations – assign, archive, move — the routine triage actions
4. Conversations – delete / mark as spam, and separately delete permanently — the destructive ones you'll want to restrict
5. Team contacts – block sender

Beyond conversations, custom roles also gate who can create or manage shared inboxes, edit shared tags, templates, and signatures, build rules and macros, invite and manage teammates, access analytics and sequences, and even create, edit, or delete roles themselves.

Here's the honest catch, and it's the one to plan around: custom roles and granular permissions are an Enterprise-plan feature. On Starter and Professional you get member, workspace admin, and company admin — capable, but coarse. The screen above shows exactly that boundary: an admin permission set with per-action mappings, alongside a plainly labelled banner that granular workspace permissions aren't available on the current plan. If "commenter-but-not-sender" or "can't permanently delete" is a hard requirement for your team, that requirement lives on Enterprise.

Teammate groups: teams and inbox access at scale

Teammate groups are how you stop managing access one person at a time. A teammate group, documented in Front's teammate groups guide, is a centralized list of users you can reuse in three places: inside rules (route to a group instead of naming individuals), to manage inbox access, and to manage shared contacts access. Company admins create, edit, and delete groups, and that ability can be delegated to other teammates.

Inbox access through a group is the big time-saver. Per Front's guide to managing inbox access with teammate groups, you configure it at Gear icon → Company settings → Teammate groups → (select group) → Access and permissions, then toggle inboxes on or off in the Access column. When a group is given access to a workspace, its members automatically get access to all public inboxes in that workspace — and public-inbox access is granted automatically and can't be deselected. Private inboxes, by contrast, are the ones you grant deliberately.

Two behaviours here trip people up, so they're worth stating plainly:

• Access is not the same as visibility. When you assign inbox access to a teammate group, those inboxes won't appear in members' sidebars by default. People still have full access; they just have to add the inbox to their own sidebar to see it. So "I can't see the inbox" usually means a sidebar tweak, not a permissions problem.
• Groups grant access, not roles. Group members receive member permissions by default. To make everyone in a group an admin or give them a custom role, you assign that role to each person individually — group-level role assignment isn't supported. Groups scale reach, not rank.

Where the native model runs out of road

Front's teammate and permission model is genuinely good, and its shared-inbox roots are its strength: because everyone works from the same inboxes, features like comments and @mentions and collision detection only work because teammates are modelled as real, distinct users sharing the work. Credit where it's due — this is collaborative support done properly.

But it's fair to name the edges. The granular controls are plan-gated. Member-or-admin is fine until it isn't, and the day you need "can comment but can't send" or "can't permanently delete," you're looking at Front's Enterprise tier — custom roles simply don't exist below it. SSO and the tightest security controls similarly sit on higher plans, which is standard for the category but still a budget line. And access is user-shaped: collision detection, assignment, and group access all assume a human teammate holds a seat. There's no built-in notion of a non-human "agent" that reads a conversation and resolves it — every actor in the model is a person you're paying a seat for.

That last gap is exactly where an AI layer fits, without touching any of your roles or seats. Macha runs on top of the Front you already use through the live Macha–Front connector — it does not replace Front, your teammates, your groups, or your permissions. Your access model stays exactly as you configured it. What changes is that the broader category of AI agents for customer service can now do the reading-and-resolving work a seat-based model can't automate: Macha's agent reads a conversation landing in a shared inbox, understands intent, and drafts a reply for a teammate to review — or, where you allow it, sends a grounded answer itself, pulling a real order or account status through a custom tool that turns your REST API into something the agent can call. Front decides who is allowed to act; Macha helps do the act, and its credits are consumed per AI action, never per resolution — reading, drafting, and calling a tool each have a real cost, and it's honest to price them that way. For how this sits alongside the rest of Front, see Front team inboxes explained and the wider Front shared inbox model, and Front rules explained for how groups plug into routing.

FAQ

What's the difference between a teammate and a seat in Front? A teammate is a user account; a seat is the paid license that account occupies. Front bills per seat, per month, and charges a prorated amount when you add a teammate under Settings → Teammates → Invite. Remove the teammate and you free the seat.

What roles does Front have? By default, member, workspace admin, and company admin. Members do day-to-day work in the inboxes they can reach, workspace admins manage a workspace's settings and rules, and company admins control the whole account. Custom roles with finer per-action permissions are an Enterprise-plan feature.

How do teammate groups control inbox access? A teammate group is a reusable list of users. Under Gear → Company settings → Teammate groups → Access and permissions, you toggle which inboxes the group can reach. Members automatically get all public inboxes in a workspace they're given access to (public access can't be deselected), while private inboxes are granted deliberately. Note that granted inboxes don't appear in sidebars by default.

Why can a teammate access an inbox but not see it? Access and sidebar visibility are separate in Front. When inbox access comes through a teammate group, the inbox isn't added to the person's sidebar automatically — they add it themselves. So a "missing" inbox is usually a visibility setting, not a permissions gap.

Can I add AI without changing my Front roles and seats? Yes. An AI layer like Macha connects to Front as a live connector and runs on top of your existing teammates, groups, and permissions — it doesn't replace them or consume a teammate seat. Your access model stays as configured; the agent reads incoming conversations and drafts or sends grounded replies within the workflow you already run.

Ready to add an AI agent on top of the Front access model you already trust? Start a free trial of Macha and connect it to your Front in minutes.