Organize people into teams

Plan membership and connection scope together

A team is a group of people used for access scoping and policy restrictions. Decide who owns its membership: an administrator in Durin for a local group, or the identity provider for a directory-synced group. Use the authoritative source so the intended membership survives later synchronization.

Connection scope and team policy solve different problems. Scope determines whether a member belongs to an allowed group for the installation. Team policy can tighten what that member may do. A connection’s empty team scope is organization-wide, so creating a group by itself does not restrict any connection.

Create a team

Teams let you group people and assign connections to the group rather than individuals.

1. Go to Teams in the admin workspace.
2. Click Create group, give it a name, select people, and save. Teams use these groups.
3. For directory-synced groups, manage membership in the identity provider. Locally managed groups can be edited in Durin.

Assign connections to teams

From a connection detail page, assign one or more teams. Only members of the assigned teams can route requests through the connection. If no team is assigned, the connection is available to all organization members.

Team-scoped policies

Use the team policy controls for read and write restrictions. Teams can inherit the organization policy or impose stricter restrictions; a team policy cannot weaken an organization denial. Connection assignments determine which team members can access an installation, including administrators using it.

Understand multiple-team membership

A connection assigned to Engineering and Support can be used by a member of either assigned team, subject to the remaining authorization checks. Team policies still apply to the member and can restrict an otherwise permitted action; adding a more permissive group does not cancel a denial.

Administrators can inspect installation configuration across the organization, but using a scoped connection is still subject to team access. Test the personal request path when validating scope rather than relying on what an administrator can see in the Admin workspace.

Verify the access matrix

Test a team change with real intended identities before expanding the rollout. Use a reviewed read on an allowed resource so provider errors do not obscure the membership check.

1. Confirm a member of an assigned team can discover and use the intended tool after completing personal authorization.
2. Confirm a member outside every assigned team cannot use that connection.
3. Check a member of multiple teams, especially when one team imposes stricter policy.
4. Check any intentionally organization-wide connection separately; removing all team assignments does not make it private.

Maintain scope when people move teams

Update local membership in Durin or directory membership at its authoritative source, then repeat the request check. Review the person’s other team memberships as well: access may remain valid through another assigned team.

Keep connection scope, team policy, and personal provider authorization distinct during troubleshooting. A correctly assigned member can still be blocked by a disabled installation, revoked credential, unreviewed tool, or organization policy. Changing teams should not be used to bypass those restrictions.