Group accounts

A team often needs a mailbox that several people read, such as [email protected], or a calendar that the whole team shares. A group account provides this. It is a shared account: it has an address, its own mailboxes, calendars, address books and files, and a quota, just like a user account. Unlike a user account, it has no credentials and cannot sign in. Users who are members of the group reach the group’s data through their own sign-in.

Groups are also a convenient target for sharing. Anything shared with the group becomes available to every member, so a resource can be shared with a whole team in one step.

A group is not a distribution list. Mail sent to the group’s address is delivered to the group’s own mailbox, not to each member. To distribute each message to a list of recipients, use a mailing list instead.

A group is the Group variant of the Account object (found in the WebUI under Management › Directory › Groups, Management › Directory › Accounts). The reference page lists every field, and the sections below describe those that require a decision.

Address

The group’s address is formed in the same way as a user’s. name and domainId form the address, from which the server sets the read-only emailAddress. aliases adds further addresses, under the same rules as for user accounts: each address belongs to exactly one account, group or mailing list. description is the name shown for the group.

Members

A group does not list its members. Membership is set on each user instead, in the user’s memberGroupIds field. To add a user to a group, add the group’s id to that user’s memberGroupIds (Managing accounts). Groups cannot be members of other groups.

Accounts from an LDAP, SQL or OpenID Connect directory get their memberships from the directory. When the directory names a group that does not exist yet, the server creates it.

Roles and permissions

The roles and permissions of a group decide what the group account itself may do, for example whether it may receive mail. They are not passed on to the members, whose permissions come from their own accounts.

roles takes one of two values:

• Default applies the roles in the Authentication singleton’s defaultGroupRoleIds, which by default contain the Group role.
• Custom applies a list of roleIds.

permissions then adjusts the result, with the same Inherit, Merge and Replace modes as for users (Permissions).

Quotas and settings

quotas limits the disk space and the objects of the group’s own account, and usedDiskQuota reports the space in use. Messages that members store in the group’s mailboxes count against the group’s quota, not against their own.

locale and timeZone record the group’s language and time zone.

Two fields serve Enterprise features. memberTenantId places the group in a tenant, and externalId holds the identifier assigned by a SCIM identity provider.

Example

The following object creates the shared mailbox [email protected], with the alias [email protected] and a 10 GB quota:

{
  "@type": "Group",
  "name": "support",
  "domainId": "b",
  "description": "Customer support",
  "aliases": {
    "0": {"name": "help", "domainId": "b"}
  },
  "roles": {"@type": "Default"},
  "permissions": {"@type": "Inherit"},
  "quotas": {"maxDiskQuota": 10737418240}
}

Members then see the group’s mailboxes in two ways, depending on the protocol: as shared folders in IMAP clients, and as a separate account in JMAP clients.