Shared Mailboxes, Delegation and Who Can See What

Thursday, 11:30, at Bellweather Logistics. The customer-service team shares one mailbox, the bookings address, and in the past week it has produced three tickets. Dan replied to a customer from it and the reply went out from his own address. So the customer has been writing to Dan personally. Dan is on leave from Monday. Priya's replies go out as "Priya on behalf of Bookings", and a customer has asked, politely, who Priya is. And the mailbox itself holds 240 unread messages. That is because all nine people on the team can see it and not one of them is the person who clears it. Three tickets, one mailbox, and none of them uses the word "permission", which is the word all three are about.

A shared mailbox is a mailbox that belongs to a role or a team rather than to a person. Several people open it from their own accounts. Delegation is one person being given permission to work inside another person's mailbox or calendar, as an assistant does for an executive. Both come down to the same question, which is who can see what and under whose name they may act. Nearly every ticket about them is a permission granted at the wrong level, or a mailbox with nine readers and no owner. This article is part of our Email Problems series.

It covers the three kinds of access in plain words; send-as against send-on-behalf, and how to choose. Next come the shared mailbox nobody owns, calendar delegation, and the executive assistant's access. Then come the leaver's mailbox and the access review that answers "who can see what". We finish with a short war story and the shared-mailbox request form to copy, in that order.

The Three Kinds of Access

There are three permissions a person can hold on a mailbox that is not their own. Almost every shared-mailbox ticket is about having the wrong one. The first is read and manage. The person can open the mailbox, read what is in it, file it, delete it, and reply from their own address. The second is send as. The person can send a message that appears to come from the mailbox itself, with no sign that a person was involved. So a reply from the bookings address looks to the customer exactly like a reply from "Bookings". The third is send on behalf. The person can send a message that shows both names, "Priya on behalf of Bookings". That way, the recipient knows a person acted for the mailbox.

The three are separate, and granting one does not grant the others, which is where the first ticket of Dan's week came from. He had read and manage, so he could see the customer's message and reply to it. And the reply went out from the only address he was allowed to send from: his own. Nothing was broken. The permission did exactly what it says, and what it says is not what the team needed. The table below is the whole of this section in a form the desk can keep beside the queue.

Most people need two of the three: read and manage, plus one of the two sending permissions. Nobody needs both sending permissions on the same mailbox. A request that asks for both is a request that has not decided what the mailbox is for. That decision is the next section, and it is a decision about identity rather than about settings.

Send-As Versus Send-On-Behalf, Decided

Choose send-as when the mailbox is the identity and the people behind it are interchangeable from the recipient's point of view. A bookings address, a support address, an accounts-payable address: the customer is writing to a function, and the function replies. The next message in the thread should come back to the function, not to whoever happened to answer. Send-as does that. The reply looks like it came from Bookings, and the customer replies to Bookings. When Dan is on leave the thread is still in the mailbox where Priya can see it. The cost is that the customer cannot tell who they dealt with, which for a function is the point and for a person is a problem.

Choose send-on-behalf when one named person is acting for another named person, and the recipient is entitled to know. Examples are an assistant sending a meeting change for a director or a deputy replying for a manager on leave. Another is a colleague covering a named individual's mailbox. The recipient sees that the message came from the person they wrote to, and also that someone else wrote it. That is honest and protects the person being acted for. Nobody should be able to send a message that appears to come, unmarked, from a named individual who did not write it. Send-as on a person's mailbox is a permission the desk should refuse by default, and the refusal is not a policy nicety. It is the difference between delegation and impersonation.

So Priya's ticket and Dan's ticket had the same answer. The bookings mailbox is a function. The team should have had send-as. The on-behalf permission someone granted Priya in good faith was the right permission for the wrong kind of mailbox. Set the reply address as well, so that replies to a send-as message land in the shared mailbox even when the client is set up oddly. Most services do this by default and a few need telling. Then the only question left is who reads the 240 messages, which is not a permission at all.

The Shared Mailbox Nobody Owns

A shared mailbox with nine readers and no owner has no readers. Each of the nine can see every message, and each assumes one of the other eight has it. And each is right about the other eight. The 240 unread messages at Bellweather were not a permission problem and no setting would have fixed them. They were an ownership problem, and the fix is two names. An owner decides who gets access and answers for the mailbox when anyone asks. A clearer opens it at fixed times each day and makes sure every message is answered, filed or assigned. The owner is usually the team's manager. The clearer is usually a rota, and the rota is written down, because a verbal rota is a rota with gaps.

Both names go on the request form and in the desk's register of shared mailboxes. And the register is the document that answers most future tickets before they are raised. The register shows which mailboxes exist, what each is for, who owns it, who clears it, who has which permission, and when it was last reviewed. It is one table, kept by the desk, updated on every access change. A desk without the register answers "who can see the complaints mailbox?" by opening the mail service's admin tools and reading a list of names. Some of those people left last year. A desk with the register answers in one glance. It knows that the list in the admin tools is the thing to check against, not the thing to trust.

The commonest ownership failure is the mailbox whose only real reader has gone. A shared mailbox is created for a project, and three people are given access. Two of them never open it, the third leaves, and the mailbox keeps receiving. I have found mailboxes in that state with over a thousand unread messages, including supplier queries, a job application and one resignation. The register catches this if the review happens; the review is the subject of its own section below. Shared mailboxes do not go quiet when they are abandoned. They go on being written to, by people who think somebody is reading.

Calendar Delegation

Calendar delegation is the same three-level idea applied to a calendar. It produces its own tickets because the levels are named differently and the consequences are visible to everyone invited. At the bottom, a person can see another's calendar: free and busy only, or the titles of meetings too. In the middle, they can add and change meetings in it. At the top, they can accept, decline and send invitations on the calendar owner's behalf. That is the assistant's level and the one that most calendar tickets are about. A delegate at the top level who sends an invitation does so marked as on behalf of the owner, which is the right default and should not be undone.

Private meetings are the edge to be clear about before granting anything. Most services let the calendar owner mark a meeting as private, and most let the owner choose whether a delegate can see private items. The decision is the owner's, and the desk should ask it explicitly on the form rather than assume. An assistant who can see the director's medical appointment and a director who did not know are a ticket of a very different kind. Write the answer on the request. Nobody has ever complained that the form asked.

The second calendar ticket is the one where a delegated calendar sends invitations under the wrong name. That is because the delegate set up the meeting in their own calendar and added the owner as an attendee. They did not create it in the owner's calendar. The fix is a two-minute explanation and a note in the knowledge base, not a permission change. The mistake comes up often enough that the explanation is worth writing once with a picture. The craft of that article is in Writing KB Articles People Can Follow. The calendar one is a good first candidate because the mistake is so easy to show.

The Executive Assistant's Access

The executive assistant's access is the delegation case with the most at stake, and the rule is short. The assistant gets delegated access to the mailbox and the calendar at the level the executive chooses, and never the executive's password. Delegated access does everything an assistant needs, reading, replying on behalf, managing the calendar and the inbox. It keeps the record honest, because every action is done under the assistant's own sign-in and can be told apart from the executive's. A shared password does the same work and makes every action in the mailbox indistinguishable from the executive's own. That protects nobody, least of all the executive. When the request arrives as "just give her my password, it's only for a week", the conversation that follows is the one in Saying No Upward. That conversation ends with delegated access set up in ten minutes.

Working with and through the assistant day to day, including when the assistant is the requester for the executive's own tickets, is the subject of Working Through the Executive Assistant. This article adds only the mailbox mechanics. Record the level granted and the private-items decision in the ticket and the register, and review it when either person changes role. Remove it on the day either of them leaves. The assistant who moves to another director keeps the old director's mailbox access far more often than anyone would guess, because nobody raised a ticket to remove it. The register is where the desk notices.

One habit belongs here because this is where it is most often broken. If a request arrives with a password in it, whether the executive's or the mailbox's, remove the password from the ticket. Tell the requester it has been removed and why. An internal note, in QuerySolv or in any other tool, is for the desk's working and never for a secret. A ticket is read by more people over its life than anyone imagines when they write in it. The desk that handles executive mailboxes gets to be trusted with them by being visibly careful about exactly this.

The Leaver's Mailbox

The leaver's mailbox is the shared-mailbox request that arrives from a manager on the leaver's last day, or the day after, and reads "I need access to Sam's email". The offboarding process owns the decision about what happens to a leaver's mailbox. That includes how long it is kept, who may read it and whether mail is forwarded. The decision is set out in The Leaver's Data and Mailbox. The desk does not make that decision afresh on each request. What the desk does is the mechanics, and the mechanics are the same three permissions as any other shared mailbox. The leaver's mailbox is turned into a shared one, or its mail is forwarded, for a bounded period. Named people are given read and manage and, if the role needs it, send-on-behalf, never send-as.

Two things are never done. Nobody signs in as the leaver, because the account is disabled on departure. Another reason is that a sign-in as a person who has left is an act that cannot be told apart from the person themselves. And access is never open-ended; the request names an end date, the register records it, and the mailbox is closed on that date unless someone asks, in writing, for more. Link the mailbox ticket to the offboarding ticket so that the two histories read as one. In QuerySolv the linking of related tickets is ordinary ticket work. The leaver's mailbox is the case where it matters most, because the question "who had access to Sam's mail after Sam left?" is one the organisation may need to answer precisely.

Who Can See What: The Review

The review is the quarterly pass through the register that asks three questions of every shared mailbox and every delegation. Does this mailbox still have a purpose? Does every person on it still need the permission they hold? And has the owner confirmed both? The owner answers; the desk asks. The pattern for getting owners to answer, which is the hard part, is in Access Reviews Managers Actually Complete. Shared mailboxes are the easiest place to start it, because the list is short and the owner usually knows the team by name.

The review finds the same things every time, and it is worth knowing them in advance so that nobody is surprised. People who left the team and kept access. Mailboxes created for projects that ended. An assistant with access to two executives, one of whom they no longer work for. A send-as permission on a named person's mailbox that somebody granted during an emergency and nobody removed. And at least one mailbox nobody can explain, which was created by a technician who has since left, for a reason that was presumably good. Remove what the owner does not confirm, record the review date, and expect the next one to be shorter.

A Short War Story: The Letter in the Claims Mailbox at Stonebridge Insurance

Stonebridge Insurance's claims team shared a mailbox that eleven people could read. When Farah on the desk pulled the register she found it had no owner recorded, no clearer, and three readers who had left the company. A message from the regulator, asking for a response to a complaint within ten working days, had arrived in that mailbox and sat unread for nine of them. That was because each of the eight remaining readers had assumed one of the other seven was handling it. Each was quite right about the other seven. The complaint was answered on the last afternoon by a claims manager who had been forwarded it by a colleague's colleague. The organisation spent roughly twenty hours over the following fortnight explaining to the regulator why its first reply had come so late. Farah's desk gave the mailbox an owner and a clearing rota that week, and removed the three leavers. The desk put every shared mailbox through the register and a review over the next month. The review found two more with no owner. The lesson the claims director repeated at the next management meeting was the one Farah had written on the ticket. A mailbox with eleven readers and no owner has no readers at all.

The Shared-Mailbox Request Form

The form below is the one request that creates, changes or reviews a shared mailbox. And it stops most of the confusion in this article before it starts by asking the questions the desk would otherwise ask in three replies. It names the owner and the clearer, and lists each person against exactly one sending permission. It records where replies go and whether private calendar items are visible, and fixes a review date. Put it on the request form for the department that owns mailboxes, and refuse, politely, to create a shared mailbox from a chat message. The form is the first entry in the register; the register is what the review reads.

SHARED MAILBOX REQUEST — ONE PAGE
Mailbox name: ____________________   Address: ____________@example.com
Purpose, in one line: ______________________________________________
[ ] New mailbox     [ ] Change to an existing mailbox     [ ] Review only

OWNER
  Name: ____________________   Role: ____________________
  The owner approves every access change and answers the quarterly review.

CLEARER
  Name: ____________________   Backup: ____________________
  Opens the mailbox at least ____ times each working day; every message is
  answered, filed or assigned by the end of the day.

ACCESS: one line per person, one sending permission per person
  Person                 Read and manage   Send as   Send on behalf   Calendar
  ____________________   [ ]               [ ]       [ ]              [ ]
  ____________________   [ ]               [ ]       [ ]              [ ]
  ____________________   [ ]               [ ]       [ ]              [ ]
  ____________________   [ ]               [ ]       [ ]              [ ]
  Send as: the mailbox is a team or a function and replies return to it.
  Send on behalf: one person acts for another and the recipient should know.
  Send as is not granted on a named person's mailbox.

REPLIES AND CALENDAR
  Replies to messages sent from this mailbox go to: [ ] the mailbox  [ ] the sender
  Calendar delegates can see private items: [ ] yes  [ ] no   Decided by: __________

END DATE AND REVIEW
  Access ends on: ________ or [ ] ongoing, reviewed every quarter
  Next review date: ________   Access removed on leaving the team: on the
  offboarding ticket, same day.

APPROVAL
  Owner: ____________________   Date: ________
  Desk: ____________________    Ticket: ________   Register updated: [ ]

Bellweather's three tickets closed on one form. The bookings mailbox got an owner, the team lead, and a clearer rota of two people a day. The nine readers were given send-as and the on-behalf permission was removed. And the 240 messages were down to a dozen by the following Tuesday, because somebody's name was now against the job. Dan's customer was told, by Priya, from Bookings, that the thread would be looked after while Dan was away. The customer did not ask who Priya was. The message had not said.

The standard that makes every shared mailbox look like this one, applied across the organisation rather than ticket by ticket, is one of the measures in Reducing Email Tickets. This article is the form and the reasoning; that one is the rollout.

Frequently Asked Questions