A request to add someone to a shared mailbox can look like a routine support task, but it changes access to business communications that may be used by several people. An MSP needs to know who is requesting the change, what level of access is intended and when that access should end. A consistent process keeps a simple administration task from becoming an undocumented permission change.
Receive the request through the agreed support route
Keep mailbox access changes in the provider's normal ticketing or service process. A traceable request gives technicians a clear reference and avoids relying on informal messages that may not show who authorised the change.
Confirm the requester is authorised
Follow the client's established approval arrangement before adding or removing access. A user asking on behalf of a colleague should not automatically be treated as the person authorised to decide who can read or send from a shared mailbox.
Identify the exact mailbox
Similar display names can create confusion, particularly where a client has several departmental or project mailboxes. Record the specific managed resource through the provider's normal system before making the change.
Clarify the access required
Reading a mailbox, sending from it and other available permissions are not necessarily the same thing. Apply only the level the authorised request requires rather than granting a broad standard set without checking the intended use.
Keep temporary access visibly temporary
If access is needed for holiday cover, a project or another limited period, record the expected review or removal point through the service process. Temporary permissions can otherwise remain long after the original need has ended.
Make the technical change through the approved method
Use the MSP's established administration process and relevant managed platform controls. Avoid undocumented shortcuts that make it difficult for another technician to understand how access was granted.
Confirm the requested outcome
After the change, verify that the intended permission has been applied and record completion. If platform propagation or another dependency means the user cannot use the access immediately, communicate the factual status rather than marking the request complete prematurely.
Keep the access history useful
Document who was added or removed, the authorised scope and the completed action without adding unnecessary personal information. A concise history helps future support when the client asks why a user has access or requests another change.