> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/users-and-access-management/teams.md). # Team-based organization Use teams to manage who may see and change which resources, and to narrow the UI to the alerts and resources one team cares about. A team owns resources — alert sources, escalation policies, schedules, services — and has members. Ownership decides who may see and change those resources; membership decides what each person sees when they switch to that team's context. Teams solve two problems at once in a large account: permissions that would otherwise need per-resource rules, and a UI showing hundreds of alert sources when a given person cares about six. Teams require the [Scale plan](https://www.ilert.com/pricing) or higher. {% hint style="info" %} Teams are optional. With no teams in the account, the team-specific UI disappears and every resource is shared globally — which is the right setup for most small accounts. {% endhint %} ## The team filter The team filter switches the whole UI between team contexts. It sits at the right of the navigation bar and offers: * **All teams** — every object you have permission to see, including objects owned by no team * **My teams** — objects belonging to teams you are a member of * **A specific team** — objects owned by that team
The right-hand end of the ilert navigation bar: a search field, the announcements icon, and a people icon labeled All teams with a dropdown arrow.

The team filter, showing the current context. Click it to switch.

Once an account has many teams, the filter adds a search field so you can jump between contexts without scrolling. The team filter is available in the mobile app too, and your selection is stored per user and synced across devices — so you pick up on your phone where you left off on your laptop. {% hint style="info" %} The team filter disappears when you have no selectable teams. It also has no effect on the team management UI itself: everything you have permission to see is assignable to a team there, regardless of the current filter. {% endhint %} ## Create a team Admins and the account owner can create teams. So can a User who has been made [Team Admin](#team-roles) of an existing team, for that team. In the sidebar, go to **Settings** → **Teams**, click **Create new team**, and enter a name. You can then add members and resources.
A team detail page in ilert showing the team name, its visibility, its four members with their roles, and the resources it owns, including alert sources, escalation policies, and on-call schedules.

A team owns resources as well as members.

You can also set team ownership from a resource's own edit view. Every resource that supports ownership has a **Teams** field:
The edit view of an alert source in ilert, with a Teams selector at the top holding one team chip, above the name, integration type, and escalation policy fields.

The Teams field decides which teams manage the resource.

If you have write permission on no team, the team selector does not appear in edit views at all. ## Private teams A private team restricts visibility of the team, its resources **and its members** to the team's own members. Global admins and the account owner still see everything. To make a team private, open its edit view and choose **Private** under **Team visibility**.
The edit view of a team in ilert, with Team visibility offering Public and Private radio options, above a members table listing each member's team role and global role.

Each member also carries a team role, which is separate from their global role.

{% hint style="warning" %} **What happens to a resource owned by both a private and a public team?** Private wins. The resource is visible to members of both teams and to nobody else — members of other teams cannot see it, even though one of its owners is public. These resources are marked with the incognito icon in list views. {% endhint %} ## Team roles A team role extends a member's permissions inside that one team. A Responder who holds the **Team User** role in a team has User permissions on that team's resources, and Responder permissions everywhere else. The available team roles are **Stakeholder**, **Team Responder**, **Team User** and **Team Admin**. Their permissions mirror the [global roles](/users-and-access-management/user-roles-and-permissions.md#role-permissions) of the same name, scoped to resources the team owns. {% hint style="success" %} **Prefer team roles over global roles.** Keep everyone who does not need account-wide write access on the global **Responder** role and grant permissions through team roles instead. A user with global Responder plus the **Team User** role gets full control of their own team's resources and nothing else — which is usually what "make them a User" was meant to achieve. {% endhint %} In a **public** team, a team role cannot be less permissive than the global role. A global User cannot be given the Team Responder role, because they already have User permissions everywhere. In a **private** team, team roles do take precedence, so a global User can be restricted to Team Responder there. {% hint style="warning" %} Global Stakeholders and Viewers cannot hold a team role. Stakeholders are team-scoped by definition; Viewers already have account-wide read-only access. {% endhint %} ## Who may change resource ownership {% hint style="danger" %} Adding or removing team ownership of a resource requires being a member of that team with write-level team permissions. This applies to every global role except Admin and account owner, who can always do it. Deleting a resource counts as removing all of its ownerships. {% endhint %} Worked through: a global **User** who is a member of *Team 1* with the **Team User** role cannot delete an alert source owned by both *Team 1* and *Team 2*, because they are neither an Admin nor a write-level member of *Team 2*. They can remove *Team 1*'s ownership, leaving the resource owned solely by *Team 2*. ## Resource visibility With the **All teams** filter, an administrator sees every alert source in the account. Someone in the Mobility team with that team selected sees only that team's alert sources. * Resources and members of **public** teams are visible to anyone with read permission. * Resources owned by **no** team are treated as public. * Resources owned by a **private** team are visible only to its members, plus admins and the account owner. ## User visibility All users are visible to everyone except **Guests** — until a user joins a private team. From then on that person is a *private user*, visible only to members of the teams they belong to, plus admins and the account owner. ## Alert visibility Within a team context, an alert is visible if any one of these holds: * its alert source belongs to the team, or * its escalation policy belongs to the team, or * the reader is a responder on the alert The third rule is what lets an alert be handed across team boundaries without moving the alert source. ## Data visibility in reports The current team filter applies to alert, on-call and notification reports: it changes both which resources appear and which data each reader may see. {% hint style="info" %} Report permissions are evaluated when the report is read, not when it is shared. Moving an alert source into a private team hides its alerts from an already-shared report URL for anyone without access. {% endhint %} ## FAQ ### Do I have to configure teams? No. Teams exist for larger organizations that need permission boundaries. Without them, all resources are shared globally and the team UI stays hidden. ### Why is there no Guest team role? A Guest has no global read permission by design — team membership is the only thing that grants them any visibility. A team role with no read permission would grant nothing. ### Why is there no Viewer team role? Viewers already read everything in the account, so scoping them to a team would add nothing. They cannot manage alerts or take on-call regardless of team membership. ### What happens when I turn a private team public, if its team roles are less permissive than the members' global roles? Those roles are raised to match. A global User holding Team Responder becomes Team User. ilert warns you on the settings page before applying it. ### Can two teams be completely invisible to each other in one account? Yes. Give every user the global **Responder** role and the **Team User** role in their own team, so new resources must be assigned to a team. Make every team private, and keep each user and resource in exactly one team. Put the account owner in a private team of their own, and delete the default escalation policy. ### I am a Team Admin and the user I want to add does not appear in the dropdown Most likely they are already in a private team you are not a member of, which makes them invisible to you. See [user visibility](#user-visibility). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ilert.com/users-and-access-management/teams.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.