Role-Based Access Controls (RBAC)

FireHydrant offers user roles to help restrict and define access to parts of the platform, enabling you to create a secure and scalable incident management process.

Users, Roles, and Definitions

Licensed vs. Unlicensed users

• Licensed users - Users with FireHydrant accounts and login access, split into 4 access roles (see next section)
• Unlicensed users - Everyone else. Users who cannot log in and perform the vast majority of actions with one exception.

Any user in Slack or Microsoft Teams, including unlicensed, can still join incident channels/chats, keep tabs on an open incident, and participate in conversations within those channels. However, unlicensed users can't take any actions that change the incident state, such as running most commands, posting updates, assigning/completing tasks, being assigned roles, etc.

Depending on your settings, Unlicensed users can perform a set of basic essential tasks from integrated chat applications like Slack or MS Teams:

• Declare incidents (can be configured in Integration settings)
• Page and Lookup On-Call (Slack only)
• ...and more

For full details, visit the command docs pages for Slack and Microsoft Teams.

Access Roles vs. Incident Roles

Access roles (this page) are for determining user access to different features and capabilities on the FireHydrant platform. These should not be confused with Incident Roles, which are titles provided to specific users on incidents and can change what tasks are assigned to them and impact other automations in Runbooks.

Organization vs. Team-Level Permissions

FireHydrant allows you to customize permissions both at an organization level (access roles) as well as within a team (called Team-Level Permissions). Certain permissions at the organization level will override team-level permissions (e.g., access roles with Manage Teams permission can manage and modify members and settings on any of the teams), but within a team, users can be given permissions to modify team-only items like schedules, policies, team membership, and more.

Access Roles, custom or out-of-box, are defined at the organization level. For more information about team-level permissions, see Team-Level Permissions below.

Predefined Access Roles

FireHydrant offers four access roles out-of-box. Any modifications or other desired behaviors should be done via custom access roles (see next section).

• Owner: Full access to the full platform, including user administration, integrations, API Keys, and other organization settings
• Member: Full access to update incident management processes, Runbooks, Settings, Teams, and Alert configurations
• Collaborator: Basic incident response access but cannot update settings or Runbooks. Same as Viewer for creating and responding to alerts if assigned
• Viewer: Read-only access to incidents and analytics in the FireHydrant web app. Ability to create and respond to alerts if they're assigned
• Unlicensed: Not a custom access role, but included to visually demonstrate what people without FireHydrant accounts can do.

Alerting Permissions

📘

^Note:

Users will always be able to interact with alerts that are targeted at them, even if they don't have explicit "Respond to Alerts" permission.

Analytics Permissions

Incident Management Permissions

📘

**Note

Users without private incident access (all-encompassing) can be added to individual private incidents on an ad-hoc basis by people who do have access. See Private Incidents for more information.

Integration Management Permissions

Resource Management Permissions

User Access Control Permissions

Custom Access Roles

Any Owner or access role with Manage Users permission can navigate to the User settings page and update another user's role. The exception to this is that users cannot update their own roles - they must request another user with adequate permissions to modify their assigned access role.

Additionally, you can update user roles using our SCIM API and your IDP (Okta, Active Directory, etc.). Read our SSO with SCIM docs to learn about provisioning users and roles.

Any Owner or access role with Manage Roles & Permissions can navigate to the Roles & Permissions page and create/make changes to custom access roles.

Creating Custom Roles

1. Navigate to Settings > Roles & Permissions and then click on "+ Add role."
2. On this next page, supply a Name and Description for this custom role you're creating.
3. Below on the same page, you can select the permissions you would like this particular role to have. The full list of selectable permissions can be browsed below.
   1. NOTE: Certain permissions will require and automatically check other prerequisite permissions/dependencies. For example, to fully read incidents, the user must also have read access to several other objects like teams and alerts. You'll receive a popup notification stating what additional permissions will be checked, if any.
4. Once configured, click "Create role" at the top right.
5. Remember to go to Settings > Users and assign your new custom role to one or more users in order to set and customize their permissions.

On the role creation page, you also have two utility buttons:

• Clear All will uncheck all boxes
• Reset will revert the form back to what it was before any changes were made. If editing a role, it reverts permissions to their prior state, and if creating a new role, it does the same thing as Clear.

Team-Level Permissions

In addition to organization-level access roles, teams can lock down configurations for their teams. This will federate permissions for each team member to modify specific resources within the team, even if they don't have permissions broadly across the org to do the same (e.g., they can manage Users within the team, but they cannot broadly manage Users in the organization).

These permissions can be found by clicking on the ellipses next to each member in the members list.

Runbooks and Service Catalog components can have assigned Owning Teams, which prevents non-owning-team members from modifying or managing those resources. Team-level permissions, in these cases, will take precedence over org-level permissions.

For example, let's say Service A is owned by Team A, User X is part of the team, and User X doesn't have Manage Service permissions within the team. At this point, it doesn't matter if the user's assigned organization role has Manage Service permissions - they will not be able to edit Service A. See the following graphic for a visual representation:

For Signals-specific features (Alert Rules, Schedules, Policies, etc.), see the next subsection.

📘

Note:

Team-level permissions override org-level permissions, with only one exception. In other words:

• If Service A or Runbook A are owned by Team A, then nobody outside of Team A can modify that service or runbook even if they have Manage Service Catalog or Manage Runbooks permissions assigned to their org-level role.
• If Team A has chosen to lock down its Signals settings, then even users with Manage Escalation Policies permission at the organization level cannot edit Team A's escalation policies.

The exception to this is for users with Owner access role. Owners can be thought of as superadmins with access to everything.

Signals-Specific Feature Permissions

To maintain existing behavior for customers, FireHydrant has not automatically locked down permissions for Signals configurations by team to prevent a sudden loss of editing permissions from existing users.

To enable the behavior, go into a Team's settings and enable this switch for Enable Team-Only Signals Resource Management. As soon as this setting is enabled, only users who are explicitly on the membership list of this team will be allowed to modify any Signals-related config on the team (e.g., Schedules, Policies, etc.), and only if they have the team-level permission required to do so.

Frequently asked questions

I want to make sure users can only modify their own team's settings. How do I achieve this?

1. First, ensure that a user does not have Owner permissions, as Owners can modify all configurations on any team.
2. Users assigned Manage Teams permissions at the organization level can modify Team details, settings, and memberships across all teams. If you don't want this, make sure that a user only has Read Teams permission.
3. Then, make sure that the individuals on the team have the team-level permissions enabled for anything you want them to be able to manage.

This flow is useful for configuring e.g., Team Leads, who can manage their own teams but not other teams.

Can an unlicensed user access incident retrospectives?

FireHydrant's incidents and retrospectives are a part of the web application and require a license to access. Retrospectives can be exported as PDF or supported integrations like Confluence and Google Docs to be shared broadly.

For more information, visit Preview & Export Retrospectives.

Can a Viewer or non-licensed user “star” events to be included in the export timeline?

-Starring events is considered a state-altering action, and subsequently is not available for the default Viewer role or anyone without Manage Incidents permission.

If a Viewer or unlicensed user posts chat messages into the incident Slack or Microsoft Teams channel, will those still be recorded by FireHydrant into the timeline

Yes, all messages in incident channels are recorded in the incident timeline regardless of who they're from.

Can a Viewer or non-licensed user be assigned action-items?

Users must at least have Manage Incidents permissions or be Collaborator+ (of the out-of-box roles).

Can a non-licensed user view the status page?

Yes. You do not need to be a licensed user on FireHydrant to view a status page.