Permission Model

EntryLayer evaluates permissions in layers. This keeps organization administration separate from actual record visibility.

When to use this page

Use this page when configuring project access, explaining why a user can open an admin surface but not read records, or composing SQL API calls such as UPSERT_ACCESS and SET_USER_SEAT.

Resolution model

Layer	Purpose	Source of truth	Typical SQL API
Organization membership	Confirms the user belongs to the app organization	EntryLayer membership	`LIST_USERS`, `SET_USER_SEAT`, `REVOKE_USER_SEAT`
Seat type	Gates feature classes such as act, build, and admin	EntryLayer seat assignment	`SET_USER_SEAT`, `LIST_USERS`
Project permissions	Grants project data actions	Project access grants	`LIST_ACCESS`, `UPSERT_ACCESS`, `UPDATE_ACCESS`, `DELETE_ACCESS`
Field-group permissions	Limits field visibility/editability inside an allowed submission	Form/project configuration	Form editor and project access configuration
Snowflake caller rights	Controls source metadata and source-backed access through Snowflake	Consumer account grants	`VALIDATE_SOURCE`, `DESCRIBE_SOURCE`

Seat type vs project permissions

seat_type is organization-level. Project permissions are data-level.

Seat behavior	What it enables	What it does not imply
`view`	Basic read-oriented product access when project permissions allow it	Build/admin tools or blanket project data visibility
`act`	Submission-oriented work when project permissions allow it	Project design or org administration
`build`	Project-building and form-design surfaces	Reading records without project `can_read` or `can_read_all`
`admin`	Organization settings, licensing, and admin SQL API usage	Automatic submission visibility

This separation is intentional: admin power should not collapse into broad data access.

Project permissions

Permission	Meaning	Scope note
`can_submit`	Create new submissions	Project-level create action
`can_read`	Read own submissions	Own records only unless `can_read_all` is also true
`can_read_all`	Read all submissions in the project	Queue and manager-style visibility
`can_edit`	Edit own submissions	Own records only unless `can_edit_all` is also true
`can_edit_all`	Edit any submission	Also requires state/workflow to allow editing
`can_delete`	Delete own submissions	Own records only unless `can_delete_all` is also true
`can_delete_all`	Delete any submission	Governed by project policy
`can_manage`	Manage project permissions and related settings	Does not automatically grant `can_read`

Own vs all

The _all flags widen scope from “my records” to “all records”.

Example grant	Result
`can_read=true`, `can_read_all=false`	User sees only their own eligible submissions.
`can_edit=true`, `can_edit_all=false`	User can edit their own editable submissions.
`can_read_all=true`	User can read all project submissions allowed by field restrictions.
`can_manage=true`, `can_read=false`	User can manage access/settings but cannot read records.

Field-group permissions

Field groups optionally restrict visible/editable fields after project-level access is granted.

Field-group grant	Effect
No grant	Field is hidden from regular readers/editors.
`read`	Field is visible but read-only.
`edit`	Field is editable if submission-level permissions and workflow state also allow editing.

Org admins and project managers may bypass field-group restrictions for management tasks, but regular data access still follows project and field grants.

SQL API examples

Grant a role read and submit access:

CALL ENTRYLAYER.API.UPSERT_ACCESS(
  'proj_123',
  'role',
  'FINANCE_TEAM_ROLE',
  PARSE_JSON('{"can_read":true,"can_submit":true}')
);

List access for review:

CALL ENTRYLAYER.API.LIST_ACCESS('proj_123');

SELECT *
FROM ENTRYLAYER.APP_PUBLIC.PROJECT_ACCESS
WHERE project_id = 'proj_123';

Set an admin seat without granting data visibility:

CALL ENTRYLAYER.API.SET_USER_SEAT('JDOE', 'admin');

Troubleshooting examples

Symptom	Likely cause	What to check
Admin sees project shell but grid/drawer says missing `can_read`	Admin seat exists without project read grant	`LIST_ACCESS`, `APP_PUBLIC.PROJECT_ACCESS`
User can read but cannot edit	Missing `can_edit` or workflow state is read-only	Project permissions and Workflow States
Field is missing from a visible record	Field-group permission hides it	Field group grants and project configuration
Cortex can call SQL API but source validation fails	Missing Snowflake caller-rights grants	Source Objects & Semantic Views