Roles and Permissions
Batida uses a role-based access control (RBAC) system to define what each member can do within an organization. Roles are hierarchical -- higher roles inherit all permissions from the roles below them.
Role Hierarchy
Owner > Admin > Commander > Responder > ViewerThe Owner is the person who created the organization. There is exactly one Owner per org, and ownership can be transferred to another admin.
Permissions by Role
| Permission | Viewer | Responder | Commander | Admin | Owner |
|---|---|---|---|---|---|
| View incidents | Yes | Yes | Yes | Yes | Yes |
| View schedules | Yes | Yes | Yes | Yes | Yes |
| Acknowledge incidents | -- | Yes | Yes | Yes | Yes |
| Resolve incidents | -- | Yes | Yes | Yes | Yes |
| Add notes to incidents | -- | Yes | Yes | Yes | Yes |
| Change incident severity | -- | -- | Yes | Yes | Yes |
| Reassign incidents | -- | -- | Yes | Yes | Yes |
| Trigger escalations manually | -- | -- | Yes | Yes | Yes |
| Create/edit schedules | -- | -- | -- | Yes | Yes |
| Manage escalation policies | -- | -- | -- | Yes | Yes |
| Manage members and invites | -- | -- | -- | Yes | Yes |
| Edit organization settings | -- | -- | -- | Yes | Yes |
| Create status pages | -- | -- | -- | Yes | Yes |
| Transfer ownership | -- | -- | -- | -- | Yes |
| Delete organization | -- | -- | -- | -- | Yes |
Role Descriptions
Owner
The Owner is the original creator of the organization. They hold full administrative access plus the ability to transfer ownership and delete the organization. There can only be one Owner at a time.
INFO
If the Owner leaves the organization, they must transfer ownership to an Admin before their account is removed. Contact support if the Owner is unavailable.
Admin
Admins manage the organization's configuration: members, schedules, escalation policies, integrations, and status pages. They can create and resolve incidents at any severity level.
This role is intended for team leads, SRE managers, and anyone responsible for maintaining incident response workflows.
Commander
Commanders are senior incident responders who can take control of an incident, change its severity, reassign it, and manually trigger escalations. They cannot modify organizational settings or schedules.
This role is designed for incident commanders -- the person leading the response during a major incident.
TIP
During a P1 incident, it's common for a Commander to take ownership of the incident while multiple Responders work on different tasks. The Commander coordinates communication and ensures the incident moves toward resolution.
Responder
Responders are the frontline team members who acknowledge and resolve incidents. They can add notes, update incident status, and be assigned to on-call rotations.
This is the standard role for developers and SREs who participate in on-call rotations.
Viewer
Viewers have read-only access to incidents, schedules, and status pages. They cannot modify any data or take action on incidents.
This role is intended for stakeholders, engineering managers, and anyone who needs visibility into incident activity without participating in response.
Changing Roles
Admins and Owners can change any member's role from Settings > Members. Select a member, choose the new role from the dropdown, and click Save.
WARNING
Downgrading a member's role revokes their permissions immediately. Make sure the member no longer needs elevated access before downgrading.
Role Recommendations by Team Size
| Team Size | Suggested Distribution |
|---|---|
| 1-5 people | 1 Owner/Admin, rest Responders |
| 6-15 people | 1 Owner, 1-2 Admins, 1-2 Commanders, rest Responders, optional Viewers |
| 15+ people | 1 Owner, 2-3 Admins, multiple Commanders per team, Responders per rotation, Viewers for stakeholders |