A neatly setup access control telling which user can do exactly what on an incident management platform can save a lot of time and hassle in the future.

In the past, Spike.sh had only 2 roles - Admin and Member. The only difference in these roles were that only Admins can remove members. It was fairly simple and most users liked it.

However, with larger teams coming onboard, it gets a little difficult to control for admins. So, we have empowered the existing system by adding two more roles. Here are all the roles you can choose from -

  1. Admin
  2. Manager
  3. Member
  4. Viewer
  5. <you can create your own role>

Check out this table to understand the difference in permissions for each role.

Permission Admin Manager Responder Viewer
Customsise roles ✅ ✅ - -
Create custom roles ✅ ✅ - -
Change user roles ✅ ✅ - -
Remove users ✅ - - -
Take actions on incidents ✅ ✅ - -
Manage teams ✅ ✅ - -
permissions against all entities*
Read ✅ ✅ ✅ ✅
Create ✅ ✅ ✅ -
Update ✅ ✅ ✅ -
Archive/Delete ✅ ✅ - -

*entities include incidents, integrations, services, on-call schedules, escalations, uptime, and automations

Visualise before changing permissions

The UI is incredibly simple for admins and managers to visualise the changes before they change permissions.

visualise access control changes before changing permissions

Responders, viewers, and any custom roles can also check permissions for other members but cannot change the roles though.

Create your own roles

For more customisations, you can create say, a Support member role, who can take actions against an incident and create more escalation policies but nothing else. This free form will allow you to add support roles, sales teams, security teams, among others.

a custom support role with limited permissions

Visit your Organisation settings > Team to access and try the new access control. Let us know what you think on kaushik@spike.sh

Special thanks to Petro Mamrai for requesting this feature.