Private teams
Restrict sensitive jobs, applications, comments, and team activity to the right workspace members.
Overview
Private teams restrict sensitive hiring work to a smaller group of workspace members.
Private teams are available on Business and Enterprise plans.
Use a private team when:
- Hiring work is sensitive, such as executive search, HR, customer data, or founder-led searches.
- A recruiting group needs a private space for jobs and applications.
- A workspace member should only access selected teams. For that case, consider using the Guest role with designated team access instead of making many teams private.
Visibility
Private teams are only visible to people who are allowed to access them.
| Plan | Who can see and administer private teams |
|---|---|
| Business | Workspace owners, admins, and direct team members |
| Enterprise | Workspace owners and direct team members. Workspace admins must be added to the team before they can see or administer it. |
Team leads can manage membership for teams they administer. Members of a private team can leave the team on their own, but they cannot re-join without being added again by an admin, owner, or team lead.
What Becomes Private
Private-team access applies to the recruiting records that belong to that team.
| Record | Visibility behavior |
|---|---|
| Jobs | Jobs owned by a private team are hidden from people who cannot access that team. |
| Applications | Applications in private-team jobs are hidden from non-members unless the application is explicitly shared. |
| Files, comments, and activity | Team-scoped files, comments, and timeline activity follow the private team's access rules. |
| Labels and statuses | Team-level application labels and statuses remain scoped to the private team. |
| Views | Team-shared views for a private team are visible only to people who can access that team. |
Candidates remain workspace-level records. A candidate can exist in the workspace while one of their applications is visible only to a private team.
Configure
When creating a team from workspace settings, turn on Make team private.
Private teams require the Business or Enterprise plan. Basic workspaces can keep reading existing private teams after a downgrade, but they cannot create new private teams or convert public teams to private.
Sub-teams under a private team must also be private. If moving or converting a team would place public sub-teams under a private parent, Attia asks you to confirm the cascade before making those teams private.
Existing-team visibility changes are enforced by the same backend rules. The team access settings UI for changing visibility after creation is coming soon.
Private Team Members
The person who creates a private team is added as a team lead. Workspace owners and admins can add active workspace members to private teams, subject to the plan's visibility rules.
Team leads can add members, promote members to lead, remove members, and manage team-scoped settings where those settings are available.
Guests can be assigned to designated teams from Clerk. A guest who is not a member of a private team cannot see that team's jobs, applications, comments, files, or activity.
Share Applications From A Private Team
Private application sharing is available on Enterprise plans.
Private application sharing lets an allowed team lead or owner share one private-team application with an active workspace member without giving that person access to the whole private team.
When an application is shared, the recipient can read the application and its related application timeline and comments. They cannot see unrelated jobs, applications, views, labels, statuses, or team settings from the private team, and they cannot share the application onward.
Sharing can be revoked. When the share is revoked, the recipient loses access to the private application and its related comments and activity.
The backend support for private application sharing is implemented. The in-app sharing controls are coming soon.
Exports
Export controls for including private-team jobs, applications, and history are coming soon.
Until the export UI is available, keep private-team export requests on the controlled backend path so access checks, audit logging, and redaction rules are preserved.
Security Considerations
Private-team data should stay behind the same access model in every surface. Avoid sending private-team job or application details to custom workflows, API clients, webhooks, or exports unless the receiving system is approved for that data and the user has the right access.
Use workspace audit logs and controlled backend actions for sensitive private-team reads, shares, exports, and membership changes.