This is a public copy of a proposal document for introducing Product RBAC to the incident.io product, a project that resulted in the following changelog release:

https://incident.io/blog/rolling-out-roles

We’ve shared it so people can see how we plan projects, of which a written proposal is often a first step.

If you like this type of working style, you can find more resources on our blog, and we’re always hiring for engineers: https://incident.io/careers

We want to restrict what users can do inside of the product, so that:

• People can’t accidentally modify global settings
• Only specific people can see sensitive data (private incidents)

RBAC can be complex, and is trickier than most features due to the serious consequences of error, that there are users with motivations to break it, and the difficulty in reversing decisions (it is easy to take one-way doors).

Any solution should be:

1. Simple and easily understandable
2. Explainable, so we can diagnose unexpected permission errors
3. Be minimally flexible while achieving product goals

The last aim is a reflection on Hyrum’s Law, which implies any possible RBAC configuration will be used by at least one customer, who is unlikely to cheer if we remove it.

This author has a preferred solution, which is where we can start this discussion:

Proposal: Predefined roles

We’ll model RBAC using predefined roles that are consistent across our customers.

Roles will have an order, where each successive role will include and build on (be a proper superset of) the previous role.

We would launch with three default roles:

• Regular User (default)
  • Create and view incidents
  • Interact with incidents, ie. create actions and post updates
• Administrator
  • Modify organisation settings, such as integrations (most of /settings)
  • Create workflows (can be delegated to user)
  • Create announcement rules (can be delegated to user)
• Owner
  • Can see all private incidents, regardless of membership
  • Approve workflows which apply to private incidents (can be delegated to admin)

Modifying roles

Each organisation has a different opinion on how roles should work, and we’ve identified a few permissions that people will want to move between roles.