Skip to content
TDACorpIDENTITYSign in

Groups, guests and custom roles

How an organization gives authority to many people at once through groups and membership sets, writes roles of its own, and brings in outside guests who are tied to a sponsor.

On this page

Permissions and roles explains how one person comes to hold a permission. This page covers the three ways an organization avoids doing that one person at a time: groups, membership sets and custom roles, and the one kind of member who is held to extra rules, the guest. None of these has a feature flag. Each is available wherever the platform and the organization allow it.

Groups#

A group is a named set of members that belongs to one organization. Anything given to the group is held by everyone in it, and groups can contain other groups.

  • Only members. A person can be added only if they are an active member of the organization, and a group or child group has to be from the same organization. A cycle is refused.
  • Nesting. Groups may be nested 4 levels deep by default, and the platform operator can change that within 1 to 8. Eight is a hard limit that no setting lifts.
  • How many. An organization may have up to 1000 groups by default.
  • Leaving. A person who is removed or suspended in the organization, or whose guest membership has expired, holds nothing through a group. This is checked when a decision is made, and does not wait for a clean-up.

Adding someone to a group is giving authority#

A new member gains everything the group holds, including what the groups above it hold. So adding a member is treated as if the person adding were granting all of that to the new member directly. The person adding has to be able to give all of it, or the add is refused. Without this, permission to manage groups would let anyone add themselves to a powerful group. Removing a member is never refused on these grounds.

A group that still holds authority cannot be deleted. Its role assignments and grants have to be revoked first. Deleting is a soft delete, so the audit history keeps pointing at it.

Groups from an identity provider#

An organization whose directory is connected with SCIM can have groups created and filled by its provider. A provider sees and changes only the groups it created and only the members it added, and it cannot take over a group an administrator made. See Single sign-on and managed accounts. Giving such a group a role is still an administrator's act.

Membership sets#

A membership set is a ready-made group that every organization has, maintained by the platform from each member's kind. There are two:

SetWho is in it
membersEvery owner and member who is not a guest.
guestsEvery guest.

A guest is in guests and never in members, so authority given to everyone in the organization never reaches a guest by accident.

What group and set assignments cannot be#

These rules hold for any assignment made to a group or a set rather than to a person:

  • Never passed on. The assignment cannot be delegable.
  • Never high risk, for a set. A membership set cannot hold a high-risk permission, because it would be given to whoever joins later.
  • Not elevation-gated. An assignment that needs a recently confirmed elevation cannot be made to a group or a set.
  • Not in the platform's own organization. That organization holds assignments to people only.
  • Not written by a guest. A guest cannot make an assignment to a group or a set.

Such an assignment is anchored to the authority of whoever wrote it. If that administrator leaves or loses it, the assignment ends with it, at decision time.

Custom roles#

A product defines its own roles. An organization can also write custom roles, which are bundles of permissions of its own. The rules:

  • Concrete permissions only. Each entry is a real permission code, not a pattern, that exists and is not deprecated. A custom role can never create a permission. A role holds between 1 and 500 entries.
  • Only what is installed. Each permission must belong to the platform's own identity namespace, or to an app installed in the organization with the permission inside its ceiling. See Installations and the entry rule.
  • Names. Lowercase letters, digits, underscores and hyphens, starting with a letter or digit, up to 64 characters.
  • A limit. Up to 50 custom roles per organization by default; the platform operator can set 0 to turn custom roles off.
  • Not in the platform's own organization, whose roles are always declared by manifest.
  • Writing one grants nothing. The authority appears only when someone is given the role, under the usual limit that nobody can give more than they hold.
  • Editing adds a version. A role is never edited in place, and an existing assignment keeps the version it was given. A retired role cannot be edited, and it cannot be given to anyone new, while assignments that exist stay until revoked.
  • Usable below. A custom role is available in the organization that wrote it and in the organizations below it, where it is given under the same limits and that organization's own ceiling still applies.

Guests and sponsors#

A guest is a member from outside the organization, for a limited time. A guest has a sponsor: an active member of the organization who is not a guest. A guest cannot sponsor another guest.

Whether an organization has guests. An organization can forbid them with the setting guests.allowed. When it is absent, guests are allowed, and a parent organization that forbids them forbids them in its children.

How long a guest stays. Every guest membership ends. If no end is chosen it is 90 days from the start. A longer end is cut back to the maximum of 365 days, and an end in the past is refused. The platform operator can change both numbers.

What a guest may be given#

A guest's authority is the sponsor's authority, narrowed. When anything is given to a guest, directly or through a group or set, all of this has to hold:

  1. The sponsor is still an active member and not a guest.
  2. It is not passable to anyone else.
  3. It ends no later than the guest membership, and it is never open-ended.
  4. It is not a high-risk permission, and not an administration permission for authorization itself. No setting lifts this.
  5. The sponsor could have given it. It is anchored to the sponsor's own assignment.

So the sponsor's assignment ending, whether revoked, expired or removed with their membership, ends the guest's authority at once. Restoring the sponsor afterwards does not bring it back.

When authority is given to a group or to the guests set, every guest it would reach must meet these rules, as if it were written to that guest directly, and a write that would reach more than 1000 guests is refused.

When a guest ends#

A guest-expiry job does three things. It runs unless the platform operator turns it off, and it is on by default.

  • Warns. Within 5 days of the end by default it records one warning for the guest. No email is sent for it today.
  • Removes. When the end passes the guest is removed, with the usual clean-up: their assignments and sessions in the organization end.
  • Suspends when the sponsor is lost. If the sponsor stops being an active non-guest member (suspended, removed, blocked or demoted to guest), the guest is suspended once a grace period of 7 days by default has passed. A suspended guest is not removed. A new sponsor, then reactivation, restores it.

An expired guest membership stops giving access when it expires, not when the job next runs. See Memberships and invitations. A sponsor whose account is suspended, but whose membership is not, keeps their guests until that changes.

Verified against commit 5d85077