Organization & teams
How members and optional teams work: org-wide vs. team-scoped resources, and who can see what.
The model: workspace → members → teams
Every workspace has two required layers and one optional one.
Teams sit on top of membership. They never replace it, and a small organization can skip them entirely.
Teams do not nest. A team is a flat named group with its own members and its own visibility setting; there is no "sub-team of a team." If you need more structure than that, model it with more teams and linked visibility rather than hierarchy.
If your organization has never created a team, you will not see team pickers anywhere; they only appear once a team exists. A two-person startup and a 200-person company use the exact same product; the second one just has more knobs.
Org-wide by default
Every team-scoped resource, including monitors, heartbeats, status pages, notification channels, escalation policies, alert routing rules, on-call schedules, maintenance windows, and incidents, can optionally belong to a team. A resource with no team is org-wide: visible to and manageable by anyone in the organization, exactly as if teams did not exist.
This is the default. Nothing you create becomes team-scoped unless you put a team into context first, either by:
- Having a team active in the sidebar switcher when you create the resource (it inherits that team automatically), or
- Using Assign to team from an existing resource's menu to move it later.
Every list, detail page, and creation form shows a small scope pill: Org-wide or the team's name. Assigning a resource shows a live preview of what that means, including who will be able to see it once it lands on that team. A team's own page goes further, summarizing how many escalation policies already route alerts to it.
Who sees what
A team has a visibility setting that controls who can see the resources scoped to it.
| Visibility | Who sees the team's resources |
|---|---|
| Org-wide (default) | Everyone in the organization, whether or not they are on the team. |
| Linked | The team's own members, plus members of any team it is linked to. Links are mutual and set up from the team's page. |
| Private | Only the team's own members. |
Private teams separate day-to-day access for regular members. Workspace Owners and Admins can still read private-team resources for administration and incident oversight. They cannot change a private team's resources merely because of their workspace role; write operations still require membership in that private team.
Regular members may see a count of results hidden in private teams without seeing the resources themselves. Owners and Admins do not need that hint because their read scope already includes those resources.
Team-local roles
Membership in a team is separate from your organization-wide role (Owner / Admin / Member / custom; see the roles reference). Inside a team you are either:
- Team admin (wire value
lead): manages the team's membership, visibility, and linked teams. - Member: sees and works with the team's scoped resources.
An Owner or Admin can inspect every team. To edit resources scoped to a private team, they must first join that team. Joining and membership changes are recorded in the audit log.
When to use teams
Most small organizations never need them. One flat member list with everything org-wide is the entire model PagerDuty-style tools give you by default too. Reach for a team when you need one of:
- Isolation: a client, a security-sensitive project, or a separate business unit that should not appear in everyone else's monitors and alerts.
- Routing: you want a subset of members to own a subset of monitors and their on-call/escalation path, without duplicating channels or policies for the whole org.
If neither applies, skip teams. Nothing about monitoring, alerting, or on-call requires one.
See also
- Add a team member: organization-level invites and roles.
- Roles reference
- On-call & schedules
- Escalation policies
Was this page helpful?