Users, Roles, And Invitations
Access control determines who on your team can do what in Incido. Roles define permission sets, invitations bring people into your organization, and the permission model ensures that sensitive actions — publishing incidents, changing billing, managing themes — are restricted to the people who should perform them.
Getting access control right matters for operational reliability. An overly permissive setup risks accidental or unauthorized changes to public communication. An overly restrictive setup slows down incident response when seconds count.
Roles and permissions
A role is a named set of permissions assigned to a user within a specific organization. Each user has exactly one role per organization. Permissions are granular — they control access to individual actions like creating incidents, editing themes, managing subscribers, or viewing billing.
Your organization includes four built-in dashboard roles when role-based access is enabled on your plan:
| Role | Typical use |
|---|---|
| Admin | Organization owner: billing, user management, org settings, SSO administration (when enabled), and full configuration |
| Manager | Platform operator: status pages, on-call schedules, monitors, themes, and workflow configuration |
| Responder | Incident commander: declare and update incidents, publish status page updates, trigger escalations |
| Viewer | Read-only access to operational data for stakeholders, leadership, or support |
New invitations default to Responder when role-based access is enabled. Adjust the role before sending if the person needs Manager or Viewer access instead.
The incident responder flag (on-call eligibility) is separate from these dashboard roles. A user can be a Viewer in the dashboard but still marked as an incident responder for paging, or vice versa.
Depending on workspace capabilities, custom roles on Business plans can further tailor permission sets beyond these defaults.
Permission boundaries prevent accidental privilege escalation and help ensure that customer-facing publishing actions remain with the right operational roles.
Roles are scoped to organizations. Having admin permissions in one organization gives you no access to another organization, even if your user account belongs to both.
Inviting team members
Invitations are email-based and token-protected. They are the onboarding path for bringing additional collaborators into an organization when that workflow is enabled in your workspace.
If the invited person already has an Incido account, they receive an "Organization Join" email and can accept the invitation to be added to your organization with the assigned role. If they are new to Incido, they receive a "User Invitation" email that guides them through account creation and organization joining in one flow.
Invitations expire after a configurable number of days. Expired invitations can be resent, which generates a new token and resets the expiration window.
Invitation workflows enforce practical safeguards such as duplicate prevention, membership limits, and identity matching so that organization access remains controlled and auditable.
When on-call is enabled for your organization, each invitation includes an explicit Incident responder choice. This flag is separate from dashboard roles: it controls whether someone can be placed on rotations, targeted by escalation policies, and assigned to incidents. The organization creator is marked as an incident responder automatically.
You can change incident responder eligibility later from the user profile page in the dashboard (when on-call is enabled) or through the organization members API (ogm_… ids). Turning the flag off is blocked while the person is still referenced by an open incident assignment, a rotation, an active or upcoming override, or a direct escalation step target.
When on-call is enabled, the Users list shows whether each member is an incident responder, and the user detail profile panel shows the same status for the current organization.
Inviting managed accounts
When your plan includes managed user accounts, each invitation includes a Manage user on accept toggle. When enabled, the user becomes a managed account owned by your organization when they accept. Managed users cannot change their name or email, cannot self-delete, and may be restricted from joining other organizations.
For the full managed-account lifecycle — request management, join policy, remove vs delete, and restore — see Managed user accounts.
Adding users on SSO domains
When SAML single sign-on is configured and a user's email domain is verified for your organization's identity provider, Incido adds them to the organization immediately without sending an invitation email. You must provide their given name and family name. The user can sign in through SAML on first access.
This direct-add path follows the same user and responder seat limits as standard invitations.
Managed accounts
Business and Enterprise organizations can own user accounts for their team members. A managed account is administered by one organization that controls the user's identity and lifecycle.
The Users list includes a Managed column for members managed by your organization. Open Users → View user to see the account type (free-floating, managed by your organization, managed by another organization, or deleted) and account management actions.
Managed accounts can be created through invitations, management requests, or SAML just-in-time provisioning. See Managed user accounts for detailed workflows.
Viewing and editing a user
Open a user from the Users list to reach the view page. The page is organized into:
- Profile — Name, email, organization role, incident responder status, and team memberships. Administrators can open Edit profile to change these values.
- Account management — Account type, join policy, and other organization memberships. Actions include Request (ask an existing member to become managed), Edit account management, and Release (return a managed account to free-floating status).
- Header actions — Remove, Restore account (for soft-deleted managed users within the restoration window), and Request password reset (for managed users in your organization).
Remove behaves differently for free-floating members and managed accounts. See Managed user accounts for the distinction between removing a membership and deleting an account.
Multi-tenancy
A single user account can belong to multiple organizations. When you log in, you see the organizations you are a member of and can switch between them. Your role, permissions, and access are evaluated independently in each organization.
This design supports consultants, agencies, and operators who manage multiple tenants. Your identity is shared, but your authority is scoped.
What changes on the public frontend
User, role, and invitation changes do not directly affect public status pages. However, they indirectly control who can publish incidents, maintenances, and updates — and therefore affect the timeliness and quality of customer-facing communication. If the people responsible for communication do not have the right permissions, public updates may be delayed or missing.
Operational effects
Access control is a reliability control, not only a security setting. If incident responders cannot publish updates quickly, communication delays become visible to customers even when technical remediation is underway. Align role boundaries with Incidents, Maintenances, and Status pages so communication responsibility is clear during high-pressure events.
Troubleshooting
A user cannot perform an action they should be able to. Check their role and permissions in the organization. Verify the role includes the specific permission for that action. If they have a custom role, compare it against the expected permission set.
An invitation cannot be sent. Check whether the organization has reached its user limit on the current billing plan. Also check whether a pending invitation for the same email already exists — duplicates are rejected.
An invitation was accepted but the user does not have the expected access. Verify the assigned role in the organization and compare it against the intended permission scope for operational tasks.
A user on an SSO domain did not receive an invitation email. This is expected when their email domain is verified for your organization's identity provider. Incido adds them directly without an invitation. They can sign in through SAML.
A managed user cannot join a second organization. Their join policy may restrict joining other organizations. An administrator can change Can join other organizations on the user's view page after removing them from other memberships.