Skip to main content

​
Overview

Permissions in Rootly are managed through roles, which determine what actions a user can perform within a team. Roles are intentionally team-scoped and product-specific, giving organizations fine-grained control over access. Each team membership assigns two roles to a user:
  • An Incident Response role, which governs incident creation, management, configuration, and analytics.
  • An On-Call role, which governs alerting, paging, schedules, escalation policies, and responder workflows.
This separation allows teams to model real-world responsibilities. For example, a user may participate in incidents without being on-call, or be on-call without having permission to administer incident configuration. When a user is added to a team, Rootly automatically assigns the team’s default roles for both Incident Response and On-Call. These defaults can be adjusted by administrators at any time.
Permissions are evaluated per team. A user may have different access levels across different teams within the same Rootly workspace.

​
AI & Agents and AI SRE

AI configuration combines product roles, seat access, and Rootly-managed feature enablement. The self-service global AI opt-in does not enable or disable AI SRE; your Rootly account team controls AI SRE availability separately. Rootly evaluates AI permissions against the currently selected team. A qualifying role or seat on one team does not grant access to another team in the same workspace. The settings and guidance below apply team-wide: to change them, switch to the target team and hold the listed role and any seat that the specific row requires. Connector viewing and management, investigation-rules management, and Private Agent inventory viewing have direct paths for eligible users without an Incident Response seat; use the paths in the matrix. An Auto-run investigation rule authorizes background execution for matching alerts. The automatic run has no initiating user and does not inherit the editor’s personal provider permissions. It uses the AI SRE background identity, the team’s configured connector credentials and allowlists, and—when enabled—registered Private Agent capabilities under the ai-sre system actor. Treat permission to manage investigation rules as permission to authorize that unattended execution boundary. See Investigation Rules and Atlas Memory for the complete boundaries.

​
Default Roles

Rootly ships with system-defined roles for both Incident Response and On-Call. These roles are created automatically for every team and cannot be deleted. Some roles are editable, while others are intentionally fixed.

​
Incident Response Roles

Incident Response includes the following default roles:
  • Owner
  • Admin
  • User
  • Observer
  • No Access
Owners have full access to Incident Response. They can configure incident settings, manage workflows and integrations, access all incident data (including private incidents), and administer platform-level features such as billing.This role is typically reserved for platform owners or the core incident management team.
Admins can configure and manage most Incident Response features, including incident properties, workflows, retrospectives, and integrations.This role is ideal for teams responsible for maintaining and improving incident processes.
Users are standard incident participants. They can respond to incidents, update incident details, assign roles, and collaborate during active incidents without having broad administrative permissions.
Observers primarily have read access but can still create incidents. This makes the role suitable for cross-functional teams such as support, operations, or customer success who need visibility into incidents.
No Access removes Incident Response permissions entirely for the team. This is useful when a user only needs On-Call access or should not interact with incidents in a given team.

​
On-Call Roles

On-Call includes a separate set of default roles:
  • Admin
  • User
  • Observer
  • No Access
In addition, On-Call supports Custom roles for more granular control.
On-Call Admins can manage schedules, escalation policies, routing rules, alert sources, and advanced features such as Live Call Routing and Heartbeats. When AI SRE is enabled, they can also manage investigation rules, including Auto-run rules, without an Incident Response seat.They can also perform bulk actions on alerts, including changing alert status, marking alerts as noise, or deleting alerts.
On-Call Users are standard responders. They receive alerts, acknowledge them, resolve incidents, and participate in on-call rotations.
On-Call Observers have limited access but can typically initiate paging. This role is commonly used for teams that need to trigger alerts without managing on-call configuration.
No Access removes all On-Call permissions for the team. Users with this role will not receive alerts or interact with paging features.
Custom roles allow teams to define precise On-Call access, such as allowing alert acknowledgement without permission to edit schedules or escalation policies.
On-Call does not include an Owner role. Administrative control is handled through Admin and Custom roles.

​
Permission Sets

Permission sets define what actions a role can perform on a specific entity. Each permission set typically includes some combination of:
  • Create
  • Read
  • Update
  • Delete
Not all entities support all actions. Some include specialized actions beyond standard CRUD behavior.

​
Incident Response Permission Sets

​
On-Call Permission Sets

On-Call permission sets control paging, alert handling, and responder operations.
These permissions determine how alerts are created, routed, escalated, acknowledged, and resolved, as well as who can configure the systems that support on-call coverage. Unlike Incident Response permissions, On-Call permissions are focused on real-time operational behavior and responder availability.
On-Call permissions govern who gets paged and how alerts behave.
They are evaluated independently from Incident Response permissions, which control incident records, workflows, and retrospectives.

​
Best Practices

  • Assign the minimum permissions required for each role.
  • Use Observers to provide visibility without administrative access.
  • Separate Incident Response administration from On-Call ownership where possible.
  • Restrict Private Incident access to a small, trusted group.
  • Clearly document Custom On-Call roles so future administrators understand their intent.

​
Troubleshooting

This usually indicates missing On-Call permissions. Confirm the user’s On-Call role includes alert update access for the relevant team.
Schedule and override permissions live on the On-Call role, not the Incident Response role. In the Rootly web app, open Configuration → Roles & Permissions, switch to the On-Call Roles tab, and open the role you want to update. Enable Create and Update under Schedule Overrides (and under Schedules if the user also needs to edit rotations themselves) or under Escalation Policies for escalation-policy management.The Incident Response Roles tab does not show any scheduling toggles — it only covers incident-related permissions — so a user whose Incident Response role is Owner still cannot manage schedules unless their On-Call role grants it for the relevant team.
Private incidents are controlled separately. Ensure the user’s Incident Response role includes Private Incident access for the team.
This may occur when seat limits are reached or when role assignments are managed through external identity systems such as SCIM.
Confirm the user is operating in the correct team and that the permission applies to the correct product (Incident Response vs On-Call).

Managing Users

The parent workflow — permissions are assigned when adding or editing users.

Managing Invitations

Invite new users into Rootly and assign them roles up front.

Security Best Practices

Broader tenant hardening — SSO, RBAC, and least-privilege guidance.