Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.refactkit.com/llms.txt

Use this file to discover all available pages before exploring further.

Every user who belongs to an organization has exactly one role in that organization: Member, Admin, or Owner. Roles are per-organization — the same user can be an Owner in one workspace and a Member in another. Permissions are validated on the server before any UI renders, so users can never access features their role doesn’t allow, even by navigating directly to a URL.

​
The three roles

Member

The default role assigned when someone accepts an invitation without a specified role. Members can view the dashboard but cannot access team management, change settings, or invite others.

Admin

Admins can manage the team — invite new members, update roles (but not for Owners), and view member lists. They cannot change workspace settings or delete the organization.

Owner

Owners have full control. They can do everything an Admin can, plus change workspace settings, update the slug and logo, and permanently delete the organization.

​
Permissions matrix

CapabilityMemberAdminOwner
View dashboard✅✅✅
Access team management❌✅✅
Invite new people❌✅ (up to Admin)✅ (any role)
Manage member roles❌✅ (non-owners only)✅
Workspace settings❌❌✅
Delete organization❌❌✅
Admins can invite new members at the Member or Admin level only. Only Owners can grant the Owner role to someone else. This prevents privilege escalation.

​
How roles are assigned

On invitation: When an Admin or Owner invites someone, they choose the role from a dropdown. Admins see Member and Admin as options. Owners see all three roles including Owner. After joining: An Admin or Owner can promote or demote existing members using the role selector in the members table. The change is applied immediately.
Admins can update the role of any member who is not already an Owner — they can promote a Member to Admin, or demote an Admin back to Member. They cannot touch Owner accounts, and they cannot assign the Owner role.Owners can change any role, including promoting a Member all the way to Owner or demoting another Owner to Admin or Member.
These constraints are enforced in the members table UI. A user can never change their own role, preventing accidental self-demotion.

​
Role implications for the UI

The role stored in the session determines what the UI shows:
  • Members who navigate to /organizations/$slug/members are immediately redirected to the dashboard — the route checks the role and calls redirect before rendering.
  • Settings pages check isOwner before rendering the Danger Zone section (delete organization). Even if a non-owner somehow reached the settings page, the delete button would never appear.
  • Role selector dropdowns in the members table are only rendered when the current user has permission to change that specific member’s role. Non-editable roles display as static badges.
Role enforcement on the client is for UX — it hides controls that would fail anyway. The actual permission check happens on the server. Never rely solely on UI visibility to protect sensitive operations.

​
Member lifecycle

When a user accepts an invitation or is added to an organization, a membership record is created that links their user account to the organization with the assigned role. Removing a member from the organization removes this record. If an organization is deleted, all its member records are removed automatically.