Easy to manage fine-grained access control and roles
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 -
- Admin
- Manager
- Member
- Viewer
- <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.
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.
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.