Manage team members, enforce role-based access control (Admin, Member, Viewer), and maintain account security in RuntimeHQ.

Organization & Access Control

The RuntimeHQ Console enforces strict, role-based access control (RBAC) across all operational workflows and control plane APIs. Every team member within your organization belongs to an isolated account domain and is assigned one of three operational roles: Admin, Member, or Viewer.

The Three Roles

RuntimeHQ separates operational execution from administrative and service lifecycle actions to protect production availability while ensuring responders have the permissions needed during incidents.

1. Admin (Full Administrative Authority)

The Admin role has comprehensive control over the organization account, team membership, and operational state.

Primary Responsibilities: Platform leads, site reliability managers, and system administrators who govern tooling, access, and service lifecycles.
Key Capabilities:
- Invite new team members and assign their roles (Admin, Member, or Viewer).
- Deactivate existing team members when offboarding or revoking access.
- Manage service lifecycles, including archiving applications and capabilities.
- Full operational access: declaring and resolving incidents, scheduling maintenance windows, creating applications and capabilities, pinning notes, and running simulations.
Built-in Safety Invariants:
- Self-Deactivation Protection: An admin cannot deactivate their own active session account.
- Last-Admin Protection: The system prevents deactivating the only remaining active administrator in an organization. At least one active admin must always exist to prevent account lockouts.

2. Member (Operational Authority)

The Member role is designed for Site Reliability Engineers (SREs), Incident Commanders, and software engineers who actively operate production systems.

Primary Responsibilities: Responding to disruptions, coordinating incident communication, scheduling maintenance windows, and registering services.
Key Capabilities:
- Declare operational state (initiating incidents) and restore state (resolving incidents).
- Schedule, update, and cancel maintenance windows.
- Link or unlink impacted applications and capabilities to active incidents.
- Add and pin operational notes within incident rooms and maintenance records.
- Register new applications and define application capabilities.
- Run non-production simulations to verify failover handling during peacetime drills.
Access Boundaries:
- Members cannot invite, modify, or deactivate team members.
- Members cannot archive applications or application capabilities.

3. Viewer (Read-Only Observer)

The Viewer role provides full visibility into operational state without allowing any mutations.

Primary Responsibilities: Customer support engineers, executive stakeholders, security auditors, or cross-functional team members who need continuous operational awareness without mutation privileges.
Key Capabilities:
- Monitor global dashboard metrics and real-time application health.
- Inspect application overview details, capabilities, and runtime keys.
- View active incidents, incident room timelines, and impact assessments.
- Review upcoming and historical maintenance windows.
- Read operational notes and cross-organizational audit logs.
Access Boundaries:
- Viewers cannot declare, update, or resolve incidents.
- Viewers cannot schedule or cancel maintenance windows.
- Viewers cannot create or modify applications, capabilities, or notes.
- Viewers cannot manage team members.

Permissions Matrix

The following table summarizes the actions permitted for each role across the RuntimeHQ Console and Control Plane API:

Capability / Action	Admin	Member	Viewer
View Dashboard, Applications & Runtime Keys	Yes	Yes	Yes
View Incidents, Maintenance & Simulation States	Yes	Yes	Yes
View Audit Logs & Operational Notes	Yes	Yes	Yes
Declare Operational State (Create Incident)	Yes	Yes	No
Update Incident Details & Link Applications	Yes	Yes	No
Restore Operational State (Resolve Incident)	Yes	Yes	No
Schedule, Update & Cancel Maintenance Windows	Yes	Yes	No
Add & Pin Operational Notes	Yes	Yes	No
Create Applications & Capabilities	Yes	Yes	No
Update Application Metadata	Yes	Yes	No
Run Non-Production Simulations	Yes	Yes	No
Archive Applications	Yes	No	No
Archive Capabilities	Yes	No	No
Invite New Team Members & Assign Roles	Yes	No	No
Deactivate Team Members	Yes	No	No

Managing Team Members

Team management is performed from the Organization Settings page (/organization).

Inviting Team Members

Only organization administrators can invite new users. When sending an invitation:

Navigate to Organization Settings (/organization).
Click Invite User.
Enter the user's email address. The domain must match your organization's verified domain. Cross-domain invitations are rejected.
Select the user's role: Member (Operational Access), Admin (Full Administrative Access), or Viewer (Read-Only Observer).
Click Send Invite.

[!NOTE] Invitations count toward your organization's seat limit. If your account reaches the seat limit, you must either deactivate inactive accounts or upgrade your plan before inviting additional members.

Deactivating Team Members

When an employee departs or transitions off the team, administrators can immediately revoke their access:

In the Organization Users table, locate the member.
Click the Deactivate User button (trash icon).
Confirm the deactivation in the modal dialog.

Once deactivated:

The user's active sessions and JWT credentials are invalidated immediately.
The user is blocked from signing in via both email and Google Workspace SSO.
The deactivation is permanently recorded in the organization audit log.
The vacated seat is freed for future member invitations.

Organization & Access Control

On this page