Search Google Appliance

Home >> Nexus >> Delegating access to email, calendar and other Nexus features >> Guidelines for Delegation and Sharing

Guidelines for Delegation and Sharing

1. Introduction

This short guide is written mostly from the point of view of approved access to – and sending of – email. Calendar sharing and delegation and the sharing of contact lists may be established similarly.

This guide has been written with regard to personal (i.e. and generic accounts (e.g. It does not consider Resource Mailboxes or the like (e.g. used for room bookings).

Further, this guide is not intended as a ‘how-to’. We have linked to on-line documentation explaining how to achieve the ‘solutions’ that are outlined here. Support expertise should be available to help you to reach these ends in colleges and departments or from the IT Services Help Centre.

2. Questions and solutions

2.1. Do any of the following apply to your situation?

Questions Solutions
Do you wish your colleague(s) to see all of your (or the generic account you own) folders, calendars, contacts, to-do lists etc? (As opposed to only the in-box and calendar for instance). If yes, you may wish to them to have Full Access to your mailbox. You can use the appropriate self-service form for Email Account Delegation to make this request. 

If no, then it is likely that you can manage the delegations and sharing through your client software.

Do you wish your colleagues to masquerade as you (or the generic account) when they send emails? If yes, then you should ask the IT Services Helpdesk to set up Send As privileges for them over the account. You can use the appropriate self-service form for Email Account Delegation to make this request. 
...or would you like colleagues to be able to Send on Behalf of you or the generic account? You may simply give them read (and write) access and Send on Behalf privileges using your client software (delegation). Alternatively you can  use the appropriate self-service form for Email Account Delegation to make this request. 
Do you need to know exactly who can see into your (or your generic) account? If yes, you should not give access to a group, whose membership can change. On the other hand, if you are the owner of the group and you actively manage the membership, this could be convenient.

If no, a group could be very convenient.

Do you wish to give access temporarily (e.g. for occasional systems support or when a temp joins your team)? If yes, then this is probably best managed by you or an assistant using Microsoft Outlook or other client software.
Do you wish to give access (or delegate) permanently to someone (e.g. a PA) who manages your (or the generic) account? This can be done either by delegation using your client software or, if Full Access and/or Send As is required, via the appropriate self-service form for Email Account Delegation.
Are you intending to swap frequently between your personal account and a generic account and wish to send email as the generic account when playing that role? If no, then it is probably best to simply open the generic account mailbox from within the client. See Outlook 2007, iCal, or Outlook Web Access for details but bear in mind that anything replied-to from the generic account may very well end up in the Sent Items of your personal account.

If yes, then this is possible by creating two profiles within Outlook. When you are in the personal profile, you will be able to see the generic mailbox messages. However, when you wish to send emails from the generic account you should switch to the role profile. Whichever profile you are working in (easily switched in a few clicks) will determine where your sent items go. If using Outlook Web Access, you can simply switch to the generic account and sent items should go in the appropriate Sent Items folder.

(A further option is to use Outlook for your personal email and OWA for your generic role, or vice versa).

Do you wish to delegate the management of the mailbox to others but do not wish them to masquerade as you or the generic mailbox? (e.g. you may wish someone to support you to assess your incoming emails, but you would not like them to pretend to be you or to send emails from the generic account). If this applies to you, consider giving someone else you trust have either Full Access to the account or shared access to your in-box. However, ensure that they do not have Send As rights. You can use the appropriate self-service form for Email Account Delegation to make this request. 

2.2. General Questions about delegation

General questions
Who should have Send As rights over my account? There are few situations where it is useful for anyone else to have Send As rights over a personal account (Send on Behalf privileges should usually suffice).

Send on Behalf privileges are usually sufficient for most generic or project accounts as well. However, you may reasonably wish to Send As a generic account (such as manager@...) if you do not want your personal identity or email address to be revealed.

What if I do not wish my personal identity and/or email address to be revealed? See the above paragraph. In this case, you will need Send As privileges over a (generic) role or project account which you can use for such communications.

Please also consider making a request to to make your email address ex-directory regarding the University Global Address List (GAL).

Why can't I permanently work within my role or project mailbox and then occasionally send an email (from that account) that is identified as being from my personal account? It is seen as a security risk to devolve privileges from a generic or project mailbox to a personal mailbox. (The reasons for this are concerned with traceability and accountability). There are very few exceptions where this is desirable.

See the ‘Are you intending to swap...’ solution for an outline as to how to switch between identities in a few moments.

What are the security implications of giving someone or a group Full Access to my account?

See also the ‘Do you wish to delegate...’ question above.

Anyone with Full Access rights to your mailbox can read and amend anything found within your account, ‘share’ access to folders to others without your knowledge, set Out of Office, manage email rules (e.g. to forward some emails elsewhere), and recover deleted items even when they have been purged out of the Deleted Items folder (as long as this is within 7 days of them being purged out of Deleted Items). Far more seriously, if someone has the credentials (username and password) to the account, they can give access to the whole of the account to others (in a very few clicks) without your knowledge.
I manage my generic/role/project account by sharing a username and password with my colleagues. Is this secure and are there other options? Many people do this around the University, especially with project accounts. However, this approach should be seen as deprecated and we are trying to encourage people away from this practice. A breach in security is very difficult to deal with and trace, given such practice.

Previously, this was the only option for such accounts but now there is a far more secure method available for such purposes. This consists of creating a new mailbox and giving access to that mailbox to one or many people. Often, this means that it is possible to trace a problem or security breach to the correct person/account, something that is simply not possible where ‘shared credentials’ are employed.

Our recommendation is: if you are already in this situation (of sharing passwords), please consider how to move away from it, if possible. If you are now creating generic or role based accounts, then please think of password sharing as a very last option: there are usually other (and better) options available to you.

2.3. Terms and Definitions

The act of an owner of an account giving another person (or group) access and possibly management rights to the account (usually including the ability to send items on behalf of the owner or account).
Full Access
Implies delegating access to the owner’s full mailbox (as opposed to some folders or calendars etc.). This does not necessarily give the second individual Send As rights.
Generic mailbox
Usually a role-based mailbox (e.g. (Previously these had their equivalent in project accounts).
Group (or security group)
(For the purposes of this document) List of individuals collectively labelled with a name.
A Microsoft Exchange term for somewhere where mail is stored (as opposed to a maillist or distribution group). A mailbox in Exchange also contains one or more calendars, contact lists and task lists.
Send As
Allowing someone to completely masquerade as the account owner or generic account/role when sending emails.
Send on Behalf of
Allows another person to Send on Behalf of a particular user/mailbox (the actual sender is also identified in the resulting email).
Allowing others to access a particular folder or feature, but does not allow them to act on your behalf. Different permission levels can be used (e.g. for read only, write, delete).


Service area: 

Written by IT Services. Latest revision 15 March 2019