Managing Users
Mange User Permissions
User’s permissions are controlled by the global role they are assigned. The Incident Response and On-Call product each has their own permission sets, so a user would be assigned a role for each respective product.
Permission Sets
Permission sets define which entity the specific role has access to. Each permission set contains settings for each of the following four action capabilities:
Create- ability to create a item for a specific entityRead- ability to view existing items for the specific entityUpdate- ability to make edits to existing items for the specific entityDelete- ability to remove an existing item for the specific entity
Incident Response Permission Sets
| Enity | Description | Links & Examples |
|---|---|---|
| Alerts | Ability to manage alert events sent to Rootly via external sources. Rootly does NOT allow deletion of alerts. Hence, there is no delete permission. Update to alert status is only done on paging alerts, which will be managed by the alert permission set for On-Call. | https://rootly.com/account/alerts |
| API Key | Ability to manage the API tokens used to integrate directly with Rootly APIs | |
| Audits | Ability to view the audit log. | https://rootly.com/account/audits |
| Billing | Coming Soon. | |
| Cause | Ability to manage the list of causes that can be used to describe an incident. Causes are classifications used to categorize the underlying reasons for incidents. They help teams analyze patterns, identify recurring issues, and improve systems by addressing the root cause of incidents. | https://rootly.com/account/causes |
| Custom Fields | Ability to manage the custom fields that can be defined to further characterize an incident. | https://rootly.com/account/form-fields |
| Environment | Ability to manage the list of environments that can be used to characterize an incident. These environments do not have direct linkage to your application environments. It’s purely an arbitrary property that can be used to better categorize incidents. | https://rootly.com/account/environments |
| Functionalities | Ability to manage the list of functionalities that can be flagged on incidents. Functionality describes the specific system/feature/product that is interrupted during an incident. | https://rootly.com/account/functionalities |
| Incident Feedback | Ability to manage the feedback collected at the resolution of an incident. | |
| Incident Roles | Ability to manage the list of incident roles that can be assigned during incidents. Incident roles help define the duties and expectations of responders during an incident. | https://rootly.com/account/incident-roles |
| Incident Types | Ability to manage the list of types that can be used to classify incidents. Incident types help organize incidents in logical categories, which can be used to identify trends, report performance, tailor response procedure, etc. | https://rootly.com/account/incident-types |
| Incidents | Ability to manage public incidents on the Rootly platform. Note: the ability to set the impacted service, assign an incident role to a user is controlled by this permission set since it’s technically making edits to the incident record. | https://rootly.com/account/incidents |
| Integrations | Ability to manage native integrations of external applications. | https://rootly.com/account/integrations |
| Invitations | Ability to manage invitations sent to users for onboarding to Rootly. | https://rootly.com/account/invitations |
| Playbooks | Ability to manage playbooks that can be used during incidents. Playbooks provide documentation on what process to follow during specific incident events. | https://rootly.com/account/playbooks |
| Private Incidents | Ability to manage private incidents on the Rootly platform. Note: Public and private incident permissions are controlled by different permission sets as teams often want to prevent non-previledged members from accessing private incidents (e.g. security incidents) | |
| Pulses | Ability to manage CI/CD events sent to Rootly. | https://rootly.com/account/pulses |
| Retrospective | Ability to manage retrospective processes and templates that get used during incidents. Retrospective processes and templates can be predefined to help teams conduct post-incident review procedures. Note: This does NOT control the ability for a user to edit retrospectives of a particular incident. This is purely for administering the process and templates. | https://rootly.com/account/retrospective-processes |
| Roles | Ability to manage global roles that users are assigned to. Roles help define what permissions a user has on the Rootly platform. Note: This does NOT control the ability to manage Incident Roles. | https://rootly.com/account/roles |
| Teams | Ability to manage the list of teams that are expected to partake in incidents. Teams represent the groups of people responsible for specific services, functionalities, or incidents within your organization. | https://rootly.com/account/teams |
| Secrets | Ability to manage secret tokens that can be used within workflows through variables, so the full secret doesn’t have to be revealed. | https://rootly.com/account/secrets |
| Services | Ability to manage the list of services that can be flagged on incidents. Service describes the specific system/component/entity that is interrupted during an incident. | https://rootly.com/account/services |
| Severities | Ability to manage the list of severities that are used to flag the criticality of incidents. Severities is used as a rating system to inform users of how critical, urgent, and impactful an incident is. | https://rootly.com/account/severities |
| Status Pages | Ability to manage the list of status pages that are natively hosted on Rootly. Note: This does NOT control the ability for a user to post to a status page. This is purely for administering the status pages that can be posted to. | https://rootly.com/account/status-pages |
| Webhooks | Ability to manage the outbound webhooks that Rootly can publish signals to specific incident and alert events. | https://rootly.com/account/webhooks/outgoing/endpoints |
| Workflows | Ability to manage the workflows used to configure automations based on incident, action item, retrospective, alert, and pulse events. | https://rootly.com/account/workflows |