← Back to Docs

Team Access & Permissions

Guides

Team Access & Permissions

Priiism uses a two-level permission system: organization roles control who can access the org and its settings, while project roles control what each member can do within a specific project. This guide covers inviting team members, understanding the role hierarchy, and managing access.

Inviting Team Members

Organization owners and admins can invite new members from org settings.

Via Org Settings

  1. Click your organization name in the sidebar
  2. Go to Settings > Members
  3. Click Invite Member
  4. Enter the invitee’s email address
  5. Select a role: Owner, Admin, Member, or Viewer
  6. Click Send Invite

The invitee receives an email with a link to join your organization. Invitation tokens expire after 30 days. If the invite expires, you can resend it from the Members page.

Via API

You can also invite members programmatically:

POST /api/orgs/{orgId}/invites
{
  "email": "[email protected]",
  "role": "member"
}

This is useful for bulk onboarding or integrating with your HR system.

Organization Roles

Organization roles determine what a member can do across the entire org.

Role Hierarchy

RoleManage MembersManage SettingsCreate ProjectsEdit ProjectsView Projects
OwnerYesYesYesYesYes
AdminYesYesYesYesYes
MemberNoNoYesYesYes
ViewerNoNoNoNoYes

Role Details

Owner

  • Full control over the organization
  • Can transfer ownership, delete the org, manage billing
  • Can promote/demote any member including other owners
  • At least one owner must exist at all times

Admin

  • Can invite and remove members (except owners)
  • Can change org settings (name, identity, SSO)
  • Can create and manage all projects
  • Cannot delete the org or manage billing

Member

  • Can create new projects
  • Can edit projects they have access to
  • Cannot invite members or change org settings
  • The default role for new members

Viewer

  • Read-only access to all org projects
  • Cannot create or edit projects
  • Cannot change any settings
  • Useful for stakeholders, clients, or auditors

Project Roles

Within each project, members can have a separate project-level role that overrides their org-level access for that project.

Project Role Hierarchy

RoleManage Project MembersEdit SettingsEdit Code/FilesView Project
OwnerYesYesYesYes
EditorNoNoYesYes
ViewerNoNoNoYes

How Project Roles Work

  • The project creator is automatically the project Owner
  • Project owners can add org members to their project with a specific project role
  • Project roles only restrict access within that project — they don’t affect org-level permissions
  • If a member has no explicit project role, they inherit access based on their org role:
    • Org Owners and Admins can access all projects as Editors
    • Org Members can access projects they created or were added to
    • Org Viewers can view all projects but cannot edit

Adding Members to a Project

  1. Open the project workspace
  2. Go to Settings > Team
  3. Click Add Member
  4. Select an org member from the dropdown
  5. Choose a project role: Owner, Editor, or Viewer
  6. Click Add

Enterprise SSO Onboarding

When your organization has enterprise SSO configured, new team members are automatically provisioned on their first login.

Just-In-Time (JIT) Provisioning

  1. A new employee gets an account in your company’s IdP (Okta, Azure AD, etc.)
  2. IT assigns them to the Priiism application in the IdP
  3. The employee visits Priiism and enters their email
  4. Home Realm Discovery detects their domain and redirects to the company IdP
  5. After authenticating with the IdP, Priiism automatically:
    • Creates a Priiism user account
    • Adds them to your organization
    • Assigns an org role based on IdP group mappings

No manual invitation is needed. The employee’s role is determined by their IdP group membership.

Role Mapping Examples

ScenarioIdP GroupPriiism Org Role
Engineering leadEngineering-LeadsOwner
DeveloperEngineeringAdmin
Product managerProductMember
External auditorContractorsViewer

See the Enterprise SSO guide for detailed role mapping configuration.

Revoking Access

Removing an Org Member

  1. Go to Org Settings > Members
  2. Find the member and click Remove
  3. Confirm the removal

When a member is removed from the org, they immediately lose access to:

  • All projects in the organization
  • All org settings and member lists
  • Any pending invitations they sent

Their Priiism user account still exists — they just no longer belong to your org.

Removing a Project Member

  1. Open the project workspace
  2. Go to Settings > Team
  3. Find the member and click Remove

When a member is removed from a project, they lose access to that specific project only. They retain access to other org projects based on their org role.

SSO-Based Offboarding

If your organization uses enterprise SSO, the simplest offboarding process is:

  1. Disable or delete the user’s account in your IdP (Okta, Azure AD, etc.)
  2. The user can no longer authenticate via SSO
  3. Their existing Priiism sessions expire based on the session lifetime setting
  4. For immediate revocation, also remove them from the Priiism org

Best Practices

Use the principle of least privilege. Start members with the Viewer or Member role and promote as needed. It’s easier to grant more access than to revoke it after a mistake.

Use enterprise SSO for teams larger than 10. Manual invitation management doesn’t scale. SSO with JIT provisioning and role mappings automates onboarding and offboarding.

Set project roles for sensitive projects. Even if someone is an org Admin, you can restrict their access to specific projects by not adding them as a project member.

Audit membership regularly. Review the Members page monthly. Remove former contractors, interns, and employees who no longer need access.

Document your role mapping strategy. When using SSO, keep a record of which IdP groups map to which Priiism roles. This helps when onboarding new IdP administrators.

Next Steps