Permission Model

42Forms uses a layered permission model. Permissions are resolved in order from most to least privileged - the first match wins.

Resolution Order

1. AUTH_DISABLED: all permissions granted (dev/test only)
2. Org membership: must be a member of the project’s org, or denied
3. Org admin/owner: full access to all projects in the org
4. Project creator: full access to that project
5. PartitionAccount record: granular per-permission booleans
6. Field group permissions: optional column-level read/edit restrictions

Partition Permissions

Each user can be granted specific permissions on a partition:

Permission	Description
can_submit	Create new submissions
can_read	Read own submissions
can_read_all	Read all submissions in partition
can_edit	Edit own submissions
can_edit_all	Edit any submission
can_delete	Delete own submissions
can_delete_all	Delete any submission
can_manage	Admin: grant/revoke permissions, approve/reject

Own vs All

The _all variants control whether a user sees only their own submissions or everyone’s:

• A user with can_read but not can_read_all sees only submissions where created_by matches their account
• A user with can_edit_all can edit any submission regardless of who created it

Field Group Permissions

For finer control, fields can be assigned to field groups. Partition accounts can then be granted read or edit access per group:

• No grant → field is hidden
• read → field is visible but read-only
• edit → field is editable (subject to submission-level can_edit)

Privileged users (org admins, project creators) bypass field group restrictions.