DOCS

Organization & teams

How members and optional teams work: org-wide vs. team-scoped resources, and who can see what.

The model: Organization → Members → Teams

Every workspace has two required layers and one optional one.

Organization

Members

Teams (optional)

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 — 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 — so the distinction is never invisible. Assigning a resource shows a live preview of what that means: who will actually 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 really means private. Even organization Owners and Admins cannot see a private team's monitors, incidents, or escalation policies until they join the team themselves — and joining is an audited action, not a silent bypass. This is by design: a private team is how a security-sensitive group, an isolated business unit, or an agency's separate client keeps its data out of everyone else's view, admins included.

Because of that isolation, an admin searching or filtering a list can come back with zero results and have no way to tell "nothing exists" from "something exists, but it's in a private team I'm not on." When that happens, HowlOps shows a count — for example, "3 results are hidden in private teams you're not a member of (joining is audited)" — without revealing anything about what those results are. It's an orientation signal, not a way around the isolation.

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 organization Admin or Owner can manage every org-wide and linked/org-visible team from the Teams page, but for a private team they still need to actually join it first — org role alone does not grant a backstage pass into a private team's data.

When to use teams

Most small organizations never need them — one flat member list, 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.