Teams and policy scoping

Teams let you scope a policy so it applies only to the people who belong to it. A policy with no team scope applies to everyone in your tenant; a policy scoped to one or more teams applies only to members of those teams. You manage teams under User Management → Teams.

How scoping works

• A policy’s scope holds a set of teams. Empty = applies to everyone. One or more teams = applies only to members of those teams (a user on any one of the scoped teams is in scope).
• Membership is what counts: when someone is on a scoped team, the policy applies to them across detection (browser extension, Gmail/Outlook, document review, and PolicyBot). Remove them from the team and the policy stops applying.
• Only active teams can scope a policy. Teams that are still pending review from your identity provider (see below) cannot be selected until you approve them.

Creating and managing teams

Anyone with Manage users (or an Admin/Owner role) can:

• Create a team — click New Team, give it a name and optional description. These are “Manual” teams you fully control in-app.
• Add or remove members — open a team and search your tenant’s users. You can only add people who already have an account in your tenant.
• Scope a policy to teams — on the policy editor’s Scope section, pick one or more teams. Only active teams appear in the picker.

Deleting a team

Deleting a team removes its memberships. To protect you from silently breaking compliance coverage:

• If a policy is scoped to more than one team, deleting one team just removes it from that policy’s scope; the policy still applies to its other teams.
• If a policy is scoped to only the team you’re deleting, the delete is blocked — that policy would otherwise apply to no one. Re-scope the affected policies first (the app lists them), or confirm the delete explicitly, in which case those policies apply to no one until you re-scope them. A restricted policy is never silently widened to your whole organization.

Syncing teams from your identity provider

Instead of maintaining teams by hand, you can have them mirror groups from your IdP. Two mechanisms exist; both create teams that start as pending and require an admin’s approval before they can scope policies.

SCIM groups (IdP push)

If your IdP pushes groups to InPolicy over SCIM, each group arrives as a SCIM team and its members are mirrored automatically. SCIM-managed teams and memberships are read-only in-app (the Edit controls are locked) — manage them in your IdP. A manual membership you added in-app is preserved and never downgraded by a sync.

Directory connection (InPolicy pull)

If you connect a Google Workspace or Microsoft Entra directory, InPolicy can pull groups you select (or all groups) and mirror them as Directory teams, including their members.

• Members are matched to existing InPolicy users by email. A group member who has no InPolicy account is skipped and reported — directory sync links existing users, it does not create new accounts.
• Google Workspace requires the group-member read scope. If you connected before this was added, reconnect the directory (delete and re-create the connection) so member sync has permission.
• Scheduled sync keeps directory teams current automatically. If a group is deleted from your directory, its InPolicy team is moved back to pending (not deleted) so any policies scoped to it aren’t silently broken. If an access token can’t be refreshed, the connection is flagged as needing re-authorization and left untouched until you reconnect.

Reviewing pending imports

Pending SCIM/directory groups appear in a Pending imports panel on the Teams page. Approve turns a group into an active, scoping-eligible team; Reject discards it. Nothing scopes a policy until you approve it — this is the gate that keeps an unreviewed IdP group from silently changing who a policy applies to.