Roles and Access Control

Farkitect uses role-based access control (RBAC) at two levels: organisation and project. This page documents what each role can do and how the two levels interact.

Organisation Roles

Organisation roles control who can manage the organisation itself — its members, settings, and structure.

Capability	Owner	Admin	Member
View organisation settings	Yes	Yes	Yes
Edit organisation settings	Yes	Yes	No
Invite members	Yes	Yes	No
Remove members	Yes	Yes	No
Change member roles	Yes	Yes	No
Create projects	Yes	Yes	No
Delete the organisation	Yes	No	No
Transfer ownership	Yes	No	No

Owner — one per organisation. Full control including destructive operations (deletion, ownership transfer). Automatically assigned to the person who created the organisation.

Admin — can manage members and settings. Ideal for team leads or managers who need to invite people and create projects but shouldn’t be able to delete the organisation.

Member — can access projects they’ve been added to. Cannot manage the organisation. The most common role for individual contributors.

Project Roles

Project roles control what a member can do within a specific project. A person can have different roles on different projects.

Capability	Admin	Contributor	Viewer
View model (Explorer, diagrams, properties)	Yes	Yes	Yes
Create/edit elements and relationships	Yes	Yes	No
Create/edit diagrams	Yes	Yes	No
Create/edit catalogs	Yes	Yes	No
Import packages	Yes	Yes	No
Export packages	Yes	Yes	Yes
Manage project members	Yes	No	No
Delete project	Yes	No	No

Admin — full control over the project, including member management. Assign this to project leads.

Contributor — can do all modelling work but can’t manage who has access. The standard role for active modellers.

Viewer — read-only access. Can explore the model, open diagrams, view properties, and export — but can’t change anything. Useful for stakeholders who need to review models without risk of accidental edits.

How the Two Levels Interact

The organisation level is the gateway. The project level is the workspace.

1. A person must be an organisation member to access any project
2. Being an organisation member alone doesn’t give access to any project — they must also be added to specific projects
3. An organisation Admin can create projects and invite organisation members to them
4. An organisation Member can only access projects they’ve been explicitly added to

Example

Person	Org Role	Project A Role	Project B Role
Chase Martin	Owner	Admin	Admin
Maya Hawn	Member	Contributor	— (no access)
Theo Gibson	Admin	Admin	Contributor
Ava Tomlin	Member	— (no access)	Viewer

Chase has full access everywhere. Maya can edit models in Project A but can’t see Project B. Theo can manage both projects. Ava can only view Project B’s models — she can’t edit, and she can’t see Project A at all.

Role-Aware UI

The Farkitect interface adapts based on the user’s role:

• Viewers see a read-only interface — edit buttons, context menu edit options, and the Palette’s drag functionality are hidden or disabled
• Contributors see the full editing interface but don’t see project member management
• Admins see everything

This means you don’t need to worry about viewers accidentally changing models — the UI structurally prevents it, backed by server-side enforcement on every mutation.

Backend Enforcement

Roles are enforced on every mutation at the Convex backend level — not just in the UI. Even if someone bypasses the UI (for example, via a direct API call), the backend checks their role and rejects unauthorized operations. The UI role adaptation is a convenience for usability, not the security boundary.