A shared inbox in Google Workspace: who sees what and who replies

An address like help@ or accounts@ starts as one person's job and becomes three people's job. The usual first attempt is a forwarding rule, which works until two people answer the same message. The second attempt is a shared password, which works until someone leaves. Google Workspace has supported answers for this, but it has more than one, they are not interchangeable, and choosing wrongly is expensive to undo once a year of mail lives in the wrong place.

The decision comes down to two questions that rarely get asked in order. Which address does mail arrive at, and which address does the reply come from. Everything else, including assignment features and whether a subscription is needed, follows from those two.

Three different things get called a shared inbox

The phrase covers three arrangements in Google Workspace, and they are built from different parts of the product.

A group used as a Collaborative Inbox is a Google group with extra features turned on. Mail arrives at the group address, members read it in the Groups interface, and conversations can be assigned and closed. This is the closest thing Workspace has to a purpose-built shared inbox.

A delegated mailbox is one person's real mailbox that other people are allowed into. Mail arrives at a person's address, and the people covering it read it inside their own Gmail. Nothing new is created, which is why this is the usual answer when the address in question is already somebody's.

A plain group or alias is forwarding with a member list. Mail arrives at the group address and is delivered to everyone's own inbox. There is no shared state at all, so two people answering the same message is not prevented, only discovered afterwards.

Most teams want the first, describe the second, and end up with the third by accident.

How a Collaborative Inbox behaves

The features are off by default. Google's description of the switch is precise:

After a group owner or manager turns on Collaborative Inbox features for a group, members with the correct permissions can use these features to manage conversations with each other. Source: support.google.com

Once on, a conversation stops being just an email thread and gains a small amount of state. A member can take it, which Google describes as being able to "assign responsibility for a conversation to yourself or another group member." A conversation whose work is finished gets marked as complete. A conversation that needs nothing gets marked no action needed, and a repeat of an existing thread gets marked as a duplicate. Labels are available for categorising.

That list is the whole feature set, and its shape is the point. Assignment, resolution and duplicate detection are exactly the three things a forwarding rule cannot do. What is absent is everything a dedicated support tool adds on top: no internal notes, no canned replies tied to the queue, no reporting on response times, no rules engine.

For a two person accounts inbox handling twenty messages a week, that absence is irrelevant and the price of zero is hard to beat. For a support queue with service level commitments, the absence is the reason third-party tools exist.

The permissions that decide who can do what

Collaborative Inbox is governed by group permissions rather than by a separate role list, and the mapping is not obvious from the interface. Google documents it action by action.

Taking or assigning a conversation "requires the Who can moderate metadata permission." Marking a conversation as complete requires the same one. Marking a conversation as no action needed, or as a duplicate, "requires the Who can moderate content permission."

The practical consequence is that a group where members can post and read but hold neither moderation permission will show the Collaborative Inbox buttons to almost nobody. This is the single most common reason a team concludes the feature does not work. The features are on, and the permissions are not.

The other consequence is about who counts as a member. External members can be added to groups, but they arrive with heavier restrictions and their posting is rate limited more tightly than internal members. A shared inbox that includes a contractor outside the organisation should be tested with that person's account before the arrangement is announced, not after.

The limits worth knowing before committing

Google publishes the group limits, and several of them decide architecture rather than just capacity.

What is limited	The documented limit
Members in one group	"Unlimited"
Groups one user can own at once	"1,500 groups"
Members added at one time through the web interface	"200 per session"
Forwarding or Cc from a Collaborative Inbox	"25 email addresses per message"
Inbound mail to one group	"300 per 5 minutes"
Mail from one sender to one group	"1,800 per hour"
Groups a user can be a direct member of	"Approximately 3,600"

Unlimited membership is the headline, and it means a company-wide announcement group and a three person support queue are the same object with different settings. The tighter number is the Collaborative Inbox forwarding cap of 25 addresses per message, which rules out using a Collaborative Inbox as a fan-out point for a large distribution.

The inbound rate of 300 messages per five minutes is comfortable for human mail and worth checking against anything automated. A monitoring system or a form handler pointed at a group address can reach that ceiling, and mail that exceeds it is not silently absorbed.

What a group inbox does to search

One difference gets underestimated until the archive matters. Mail handled in a Collaborative Inbox lives in the group's conversation history, searched through the Groups interface, while mail handled in a delegated mailbox lives in Gmail and is searched with the Gmail search operators people already know. Teams that answer from Gmail with the group address in the From line end up with copies in both places, which is convenient for finding things and confusing for anyone trying to work out where the record of record is.

Deciding that early is cheaper than deciding it later. Pick one place as the archive, tell the team which one it is, and accept that the other will be incomplete.

Who the reply comes from

This is the question that decides whether a Collaborative Inbox is usable as a customer-facing address, and it is separate from where mail arrives.

By default, a member answering in the Groups interface is answering as themselves. Their own address is on the reply. For an internal queue that is fine and often preferable, since it is clear who handled the request.

For a customer-facing address it is usually wrong, and the fix lives in Gmail rather than in Groups. Gmail allows sending from another address that is owned, and Google's help page states that on a work or school account "you can send from a group alias." Adding it requires verification, since the process ends by clicking the link in a confirmation message Gmail sends to the address being added, and for a group alias that means someone has to be able to receive that confirmation. Google notes that up to 99 addresses can be added this way, and that an administrator may need to configure the domain alias or email alias when the confirmation cannot be found.

Once the group address is verified as a send-as address, each member replies from their own Gmail with the group address in the From line. Mail arrives at the group, the shared state lives in the group, and the customer sees one consistent address. That combination, rather than Collaborative Inbox alone, is what most teams actually mean by a shared inbox in Workspace.

Collaborative Inbox, delegation, or a tool

Three options, chosen by what the address is rather than by preference.

Arrangement	Best when	The real cost
Group as Collaborative Inbox	The address is new or already a group, and assignment is the missing piece	Members work in the Groups interface, and permissions have to be set correctly
Delegated mailbox	The address is a real person's, and others need to cover it	Same organisation only. No Drive attachments and no autocomplete for delegates
Third-party shared inbox	Response times are measured, or notes and templates are needed	A subscription, and mail lives in a second system

Delegation's limits are documented as firmly as the group ones. A single Gmail account supports up to 1,000 unique delegates, with typical use allowing about 40 at the same time, and delegation only works "to another user in the same organization, regardless of their domain or their organizational unit." Two separate Workspace accounts cannot delegate to each other, which is the point at which agencies and clients need forwarding or a real tool.

The offboarding test

A shared inbox arrangement should be judged by what happens when a member leaves, because that is where the cheap options fail. Removing someone from a group takes one action and changes nothing else. Removing a delegate takes one line in the mailbox owner's settings. Changing a shared password means telling everyone who remains, in writing, which is how credentials end up in chat histories that outlive the employment.

The same test applies to joining. A new member of a group sees the conversation history that the group retains, with no data transfer and no export. A new person on a shared password sees everything immediately, including mail nobody intended to hand over, which is a disclosure rather than an onboarding step.

The part that fails on the Mac, not in Workspace

Whichever arrangement wins, the person doing the work ends up holding several identities in one browser. The group interface is one place, their own Gmail with the group address in the From line is another, and any admin console is a third. All of them are Google, all of them are signed in at once, and the browser has one session to resolve them against.

That is where replies go out from the wrong address after everything was configured correctly. The account switcher is a menu, not a boundary, and Google documents that when several accounts are signed in at once, settings from the default account can be applied because the service cannot always tell which account is in use.

Two changes make this survivable. Give the shared queue a window that is used for nothing else, and never run the personal account and the queue in the same window. A browser that keeps each web app in its own window does this structurally rather than by discipline, since each window holds its own cookie store and its own name in Command-Tab, so the queue and the personal mailbox are never one keystroke apart. Teams running two or three queues usually organise them as separate workspaces, and the rest of the surrounding stack can be checked against the supported apps first.

What to change first

Answer the two questions in order. If the address already belongs to a person, set up delegation and stop there. If it is new or already a group, turn on Collaborative Inbox features, then fix the moderation permissions before announcing it, and verify the group address as a send-as address in Gmail so replies leave from the queue rather than from a colleague. Then give that queue a window of its own, which is the habit SpaceDeck is designed to make automatic.