Shared mailboxes make team work easier, but access can outlast the task or role that originally required it. A recurring review gives workspace owners a chance to check who can use each mailbox, whether that access is still appropriate, and what changed since the last review. The goal is not to remove people automatically: it is to make a deliberate decision, record it, and confirm the result. Start with the access information available to you, then account for an important limit: the controls you can see and change depend on your role, plan, and workspace provisioning.
The useful bits
- Review each mailbox against current responsibilities, not just the existing access list.
- Record the reviewer, decision, reason, and any follow-up action.
- Confirm changes through available workspace controls, and escalate when your role does not permit them.
Set a repeatable review point
Choose a recurring occasion that fits how your team changes, such as a regular workspace check-in or the close of a project. Put the review on a calendar and name the person responsible for gathering the information. If multiple people administer mailboxes, decide who coordinates the review so that each mailbox is covered once and unresolved items have an owner.
Keep the review focused. You are checking whether current access still matches current work, not trying to reconstruct every past message or infer activity from mailbox contents. A predictable process makes it easier to notice missing decisions and follow up on changes.
Build a mailbox-by-mailbox view
For each team mailbox, note its business purpose, the teammates currently assigned access, and the roles or permissions shown to you. Compare that list with current responsibilities: who handles incoming requests, who needs to send replies, and who is responsible for oversight? Do not assume that everyone who once helped with a mailbox still needs the same role.
Use the workspace’s available administration controls only if your account has the required permissions and the relevant feature is provisioned. BITTU Mail workspace capabilities and controls vary by role, plan, and provisioning state. If an access list or role control is not available to you, record the gap and ask an authorised workspace administrator to verify it rather than treating an incomplete view as proof that no access exists.
- Mailbox and purpose
- Current teammate and assigned role, as visible
- Current responsibility that requires access
- Decision: keep, adjust, remove, or investigate
Ask a consistent need-to-access question
For each person, ask whether their present duties require access to this specific mailbox, and whether the assigned role is appropriate for those duties. A teammate who only needs to read incoming requests may not need the same permissions as someone who must manage mailbox settings. Do not infer exact capabilities from a role label unless the workspace presents those capabilities to you.
When the answer is unclear, pause rather than making a guess. Check with the person’s current work lead or the mailbox owner through your normal internal process. If a teammate has moved to another responsibility, confirm whether access should end, change, or remain for a defined handover. Record the reason for retaining unusual or temporary access so a later reviewer can reassess it.
Record decisions before changing access
Keep a concise record in an approved team document or other internal record system. Capture the review date, mailbox, reviewer, person reviewed, decision, reason, and any action owner. For a change, note who will make it and when it was completed. Avoid putting passwords, one-time codes, or unnecessary private message details in the record.
A useful record distinguishes a decision from an action. “Remove access” is a decision; “administrator updated the assignment” is an action that still needs confirmation. If the review depends on information you cannot verify, mark it as pending and specify who will resolve it. This prevents an unanswered question from being mistaken for a completed review.
Review record Mailbox: orders@example.com Person: Casey Lee Current responsibility: No longer handles order enquiries Decision: Remove access Action owner: Authorised workspace administrator Status: Pending confirmation
Apply changes within your authority
If your role provides the relevant mailbox administration controls, make only the agreed change and follow the options available in your workspace. If it does not, send the recorded request to an authorised administrator using your team’s established process. Workspace administration permissions and quotas are enforced server-side, so a request or a locally maintained checklist does not itself change access.
Do not assume an alias is an independent mailbox or login. If the review concerns an alias, shared identity, or unclear assignment, ask the administrator to explain what access arrangement is actually provisioned before deciding what should change. Likewise, avoid promising that a particular control will appear for every workspace.
Confirm completion and carry open items forward
After an administrator makes a change, check the available workspace view again, if your role permits, and compare it with the recorded decision. Confirm that the intended person and role now appear as expected, or ask the administrator to confirm completion. Record the confirmation and date. If you cannot independently view the result, document who confirmed it and leave the item marked as awaiting verification until you receive that confirmation.
At the next review, revisit exceptions, temporary access, and unresolved requests first. A practical checklist is: identify each mailbox; compare current access with current duties; decide and document; assign any change to someone authorised; verify the result; carry pending items forward. This creates a useful audit trail for team coordination, but it is not a guarantee of legal proof or a substitute for controls your workspace does not expose.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction