We’ve long believed that incidents (and technical team cultures) improve when more people are empowered to declare, follow, and contribute to their resolution. But not everyone in an organization needs to be able to manage the processes, rules, and settings a company enforces for their incident programs. Today we’re upgrading role-based access control (RBAC) in FireHydrant to include new role types and access restrictions that make it easier for administrators to administrate, responders to respond, and everyone else to get the visibility they need into incidents.
Users with these roles, Viewer and Collaborator, can be granted restricted levels of access to incident response and platform management to provide more safety and control over your organization’s incident management program.
Let’s take a closer look at what each role can do.
Declare an incident in Slack or the web UI
Log into and view incident pages in the web UI
Collaborators can do everything viewers can, plus:
Respond to incidents using all Slack commands or the web UI
Be assigned an incident role
Participate in retrospectives
Members can do everything collaborators can, plus:
Manage incident response (incident types, severities, fields, etc.)
Manage Service Catalog
Owners can do everything members can, plus:
Manage API keys
Manage the organization
It’s worth noting, we believe strongly that anyone in an organization should be able to declare an incident. So even without a designated Viewer role any member of your Slack organization can declare an incident using the `/fh new` command in Slack.
To get started with role-based access controls, update any user on the User Settings page or update your users' role using our SCIM API in your IDP. You can also read our updated documentation page on Role-Based Access Control.
See FireHydrant in action
See how service catalog, incident management, and incident communications come together in a live demo.Get a demo