Teams

A Team is a named group of administrators. Instead of assigning roles to each administrator individually, you grant roles to a Team and manage who belongs to it; every member inherits the Team’s roles. A Team can hold different roles in different contexts, so one team can administer a Sign-In context while holding read-only access to an EntryPoint context. End users have a team of their own kind, the Self-Service Team, described at the end of this page; it carries no administrator roles.

At a glance

What it is

A named group of administrators that holds roles

Members

Administrators; they inherit the team's roles. End users belong to Self-Service Teams instead (see below)

Roles

Granted to the team; different roles per context are supported

Scope

Organization and MSP partner

Source

Created manually, or synchronized from an IdP group via SCIM

Creating teams and granting roles

Creating a team and granting it roles are two separate steps, kept apart on purpose:

• Create the team and manage its members on the Teams page. A new team starts with no authority.
• Grant roles to the team under Administrators, on the Teams tab, at the organization level or inside any context. The same team can be given one set of roles in one context and a different set in another.

This separation means you can change who belongs to a team without touching what the team is allowed to do, and the reverse.

Membership

A person can be added to a team only if they are already an administrator (member) of that organization or MSP partner. If you add an email address that is not yet a member, Netgraph offers to invite them as a member first; they must accept the invitation before they can sign in.

Per-context roles

A team is created at the organization or MSP level, but it can be granted roles in each service context independently. Across the contexts of an organization (for example Sign In, EntryPoint, EasyPSK, Endpoint Manager for Cisco ISE) a single team can carry exactly the roles each context needs.

Teams from SCIM

A group synchronized from your identity provider through SCIM appears as a Team whose membership follows the IdP group. SCIM keeps the membership in step but never assigns the team’s roles; an administrator maps the team to roles in Netgraph as above.

Self-Service Teams

The platform has two kinds of team, kept apart on purpose:

• A Team, described above, holds administrators and carries administrator roles. It is managed under Admin Access Control.
• A Self-Service Team holds end users. It is a named list of email addresses, managed under Selfservice Access Control, and carries no roles of its own. It grants access through what it is bound to: a Sign In Access Policy (the team’s members match the policy beside its email patterns), an EasyPSK group (with the group roles the binding names, and optionally a welcome mail to new members), an onboarding rule (a member gets a group of their own at first sign-in) or a Site manager role.

Every member of a bound Self-Service Team gets the binding’s self-service permissions. In member lists, team-derived members are marked as such and are not edited one by one. A person who leaves the team loses what the team gave, at once; unbinding or deleting a team has the same immediate effect for all its members.

A Self-Service Team is created by hand or provisioned from an IdP group over SCIM, through the organization’s separate self-service provisioning registration. A provisioned team is marked with its SCIM origin, and its membership is kept by the identity provider.

Related sections

• Identity Provisioning (SCIM): provision teams automatically from your IdP.
• Roles and Administration Levels: the roles a team can hold.
• Administration Portal: where teams and roles are managed.
• Self-Service Teams in the wiki: creating and binding a Self-Service Team step by step.