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.

​
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.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.
Paging and configuration permissions are separate by design. Assign an On-Call role that includes schedule and escalation policy management if needed.
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).