Define Mailbox Roles Before Adding a Teammate to a Workspace

Start with duties, not titles

Write down the work the person will actually handle. For example: read incoming messages, draft replies, send messages, manage calendar items, or administer mailboxes and workspace settings. Separate routine work from decisions that affect other people or the domain.

This makes the access request more precise. “Help with email” could mean preparing replies for review, sending messages independently, or changing mailbox administration. Those are different responsibilities. A job title alone does not settle which controls the account should provide.

Match each task to the least access needed

For each duty, describe the action the teammate needs to complete and whether they need to do it independently. Ask an administrator which available role permits that work, and whether the role also permits unrelated actions. Do not assume a role name means the same thing across plans or workspace configurations.

Keep administrative work distinct from ordinary mailbox work. A teammate who needs to handle messages may not need authority over domain or mailbox administration. Conversely, if someone is responsible for administration, confirm the specific administrative scope rather than treating all administrative access as interchangeable.

Responsibility: Reply to customer enquiries.
Needed: Access to the relevant mailbox and permission to send replies.
Not requested: Domain or mailbox administration.
Confirm with: An authorised workspace administrator.

Confirm the limits with an administrator

Before adding the teammate, have an authorised workspace or domain administrator confirm the available role, any mailbox or workspace quota that applies, and whether the required control is available for the current plan and provisioning state. Workspace administration covers domains and mailboxes, but controls depend on role, plan, and provisioning. The account does not necessarily expose identical options to every user.

Ask the administrator to check the current account rather than relying on an old setup note or another workspace’s experience. Permissions and quotas are enforced server-side. If an expected action is unavailable, ask the administrator to clarify whether it is a role limitation, plan limitation, or an account that is not yet provisioned for that capability.

Use a concrete request

A useful request gives the administrator enough context to decide without asking for broad access by default. Include the teammate’s mailbox, the tasks they will perform, and any actions they explicitly do not need. If the work changes later, review the request rather than expanding access informally.

For instance, a teammate who prepares calendar invitations and replies may need access to those work areas, but that does not establish a need to manage external sending policies or other users’ mailboxes. Ask which available controls cover the actual duties; do not assume every listed workspace capability is enabled for every account.

Please add [teammate@example.com] for [team@example.com]. They need to read incoming messages and send replies. They do not need to administer domains or other mailboxes. Please confirm which available role supports these duties and whether any plan or provisioning limit applies.

Check the result using the teammate’s account

After the administrator confirms the change, have the teammate sign in with their own account and try a representative task. They might open the assigned mailbox, prepare a reply, or use the calendar function that their work requires. Confirm that they can complete the intended action and that they cannot access controls outside the agreed responsibility, where that distinction is visible to them.

If the task fails, note what happened and ask the administrator to check the account’s role and provisioning. Do not share another person’s password or one-time passcode to troubleshoot. A successful sign-in alone does not prove that the right permissions are in place; verify the work itself.

Revisit access when responsibilities change

Roles should reflect current duties, not become permanent simply because they were convenient during setup. When someone takes on a new responsibility or stops handling a mailbox, ask an authorised administrator to review the access. Confirm the updated arrangement with the teammate, especially if it changes who may send messages or administer workspace resources.

Keep a brief record of the agreed duties, the administrator’s confirmation, and the task used to verify access. This creates a clear reference for the next review without implying that every workspace has the same controls or that a particular role is available on every plan.

• List the teammate’s required actions and the mailbox or workspace involved.
• Ask an authorised administrator to confirm the available role, plan limits, and provisioning status.
• Test a representative task using the teammate’s own account, then review access when duties change.