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 starts with a default set of roles. Depending on workspace capabilities, custom roles can be used to match team structure, such as separating response actions from configuration actions.
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.
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.