Shared team inboxes
Give the team one mailbox with deliberate reading and response rights.
Connect a shared address and choose who may read, respond or manage it while role restrictions continue to govern sending and changes.
Who may use this mailbox?
| Colleague | Read | Respond | Manage |
|---|---|---|---|
| Mira Keller | Permitted | Permitted | Permitted |
| Jonas Lee | Permitted | Permitted | — |
| Alex Sommer | Permitted | — | — |
Mailbox grants and role restrictions both apply.
A common address should not mean identical authority for everyone.
A shared service or account address lets several colleagues work with the same correspondence. Tsumira separates access levels and management of that mailbox instead of distributing one private account informally. The connection still needs a working provider setup. Decide who owns the queue and who should only observe before granting access to the team's real customer conversations.
Keep role restrictions above the mailbox grant.
The user's role still applies. A viewer cannot send or change messages merely because a mailbox-level grant appears broad. Sending requires the appropriate outbound permission and an active human membership. This prevents treating an automated identity or read-only colleague as another unrestricted sender. Test the actual role and mailbox combination rather than reviewing only one settings screen.
Who may use this mailbox?
| Colleague | Read | Respond | Manage |
|---|---|---|---|
| Mira Keller | Permitted | Permitted | Permitted |
| Jonas Lee | Permitted | Permitted | — |
| Alex Sommer | Permitted | — | — |
Mailbox grants and role restrictions both apply.
A concrete workflow
Choose purpose
Identify the address and team responsibility for its conversations.
Grant access
Choose read, respond or manage for each relevant colleague.
Test roles
Verify what viewers, responders and managers can actually do.
Review use
Revisit grants and configured support links as the team changes.
An illustrative working example
Illustrative scenario: an account-management inbox
A company connects an account-management address. Several colleagues may read, selected responders may answer and one manager maintains access. A viewer tests the inbox without receiving send authority. The team agrees who takes the next reply and checks the customer-facing identity. The pilot distinguishes shared visibility from response ownership and confirms a configured helpdesk link separately if support tickets are needed.
Questions about this topic
Can all members manage a shared mailbox?
No. Management depends on appropriate role authority or a sufficient shared-mailbox grant. Reading is not account administration.
Can a viewer send if granted respond?
Role restrictions still apply. A viewer lacks outbound authority regardless of an apparently broader mailbox grant.
Does a shared mailbox automatically create tickets?
Only the configured helpdesk email-channel link provides that workflow. Verify channel activation and working background processing separately.
Is this the same as sharing a personal mailbox?
No. Personal mailboxes remain owner-only. Shared accounts have their own deliberate collaboration and management model.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Gmail
Application concept: Define who may read, respond and manage a shared Gmail service address before connecting it.
Outlook
Application concept: Compare an Outlook team address's operational purpose with explicit shared-mailbox grants in Tsumira.
Zendesk
Application concept: Review whether a Zendesk service address needs ticket-channel handling rather than merely shared email visibility.