Group teammates into departments so project visibility and shared-mailbox access scope to the group they actually work in. Support, Sales, and Marketing stop reading each other's campaigns and customer threads by default, department leads can invite within their own group without going through the account owner every time, and an individual mailbox stays private unless the owner opens it through a reason-required, logged override.
A MailInApp account that outgrows a handful of people used to have exactly one visibility model: every active editor or viewer saw every project and every shared mailbox the account owned. That's fine for a small team where everyone already sees everything anyway. It stops being fine the moment "team" means separate functional groups — support fielding customer threads, sales running its own campaigns, marketing running its own — with no real business reason for one group to browse another's.
Departments layer on top of existing roles
A department doesn't replace the owner/editor/viewer roles — it scopes what an editor or viewer within it can see. The account owner creates departments from Settings, assigns teammates to one or more, and from that point on a project or shared mailbox tagged with a department is visible only to that department's members plus the owner. A project or mailbox with no department set behaves exactly as it did before: visible to the whole account.
Department leads take invites off the owner's plate
Promoting a teammate to lead for their own department lets them invite new people directly into it — a real delegation, not just a label. A lead's reach stops at the edge of their department: they can't invite into a group they don't run, can't touch billing or credentials, and can't mint another lead. Everything that already stays owner-only — SMTP settings, Stripe Connect, API keys, webhook secrets, team management itself — stays owner-only for a lead too.
Individual mailboxes are private, not un-openable
A claimed inbound address like support@ can be shared with a whole department, or set to individual and assigned to one specific person. An individual mailbox uses a company-owned address for ordinary business correspondence, so a hard technical wall would trade away real business continuity — a departed employee's mailbox becoming permanently unrecoverable company data — for a privacy guarantee the law doesn't actually require for work correspondence on a company domain. Instead, the owner's only way into someone else's individual mailbox is Owner access: pick the mailbox, give a reason, then read it — never reply on the assignee's behalf. The access is logged, and that log is visible to the mailbox's own assignee afterward, not hidden from them.
Everyone accepting an invite sees what it means first
Because a department changes what a teammate can see, and because owner access into an individual mailbox is possible, the invite-acceptance page shows a short, plain-language notice before anyone joins: what their department makes visible, and that owner access is always reason-required and always logged. There's no separate consent flow to configure — accepting the invite means acknowledging the notice.
What this doesn't change
Editor and viewer permissions inside a department stay exactly what they already were — a department-scoped editor can still build, send, and read responses for what they can see; a department-scoped viewer is still read-only. Volume limits, plan tiers, and credential-rotation rules are untouched by any of this — departments are a visibility layer, not a new pricing axis or a new set of write permissions.
Getting started
Create departments that match your org's real structure from Settings → Team, assign teammates to them, and tag new projects with a department from the creation picker. See Departments for the full reference, Team collaboration for how roles and invites work underneath it, and Inbound mailbox for setting up the shared and individual addresses departments scope.