Seat Types & Licensing

EntryLayer uses seat_type as the organization-level capability model. Seat type decides whether a user can view, act, build, or administer product surfaces. Actual record visibility comes from project permissions, field-group restrictions, and Snowflake governance.

When this matters

Use this page when:

assigning seats to new users
explaining why an admin can manage settings but still see a missing can_read message
separating product billing from project data access
deciding which users need build/admin capabilities

Seat hierarchy

Seat type	Product capability	Typical users
`view`	Open the app and read what project permissions allow.	Stakeholders, reviewers, auditors with read-only project grants.
`act`	Work submissions where project permissions and workflow allow.	Operators, reviewers, approvers.
`build`	Create projects, design forms, configure rules, and manage build surfaces.	Data/product builders.
`admin`	Manage org settings, members, licenses, and admin SQL operations.	App administrators.

Higher tiers include lower-tier product capabilities, but they do not bypass project data permissions.

For public pricing, see Pricing. Pricing is separate from Snowflake infrastructure costs for Snowpark Container Services, warehouses, and Cortex usage in the customer’s account.

Four access layers

Layer	Example	What it controls
Snowflake account role	`ANALYST_ROLE`	Whether the person can use the installed app and source grants.
EntryLayer seat type	`admin`, `build`, `act`, `view`	Which product surfaces the user can use.
Project permission	`can_read`, `can_edit`, `can_manage`	Which project records and settings the user can access.
Snowflake source governance	caller rights, masking, row access	Which source rows and values Snowflake allows the user to see.

All four layers can matter at the same time.

Common examples

Scenario	Expected behavior
User has `admin` seat but no `can_read`	They can manage org/admin surfaces, but the record grid and drawer should not show project data.
User has `build` seat but no source grants	They can open build surfaces, but source validation or project creation can fail.
User has `act` seat and `can_edit`	They can edit eligible submissions when workflow state allows editing.
User has `view` seat and `can_read_all`	They can read project records but cannot perform build or act operations.
User has project `can_manage` but no `can_read`	They can manage project access/settings without automatically reading records.

Assigning seats

Admins can manage seats in Org Settings -> Members & Licenses or through the admin-only SQL API:

CALL ENTRYLAYER.API.SET_USER_SEAT('USERNAME', 'admin');
CALL ENTRYLAYER.API.REVOKE_USER_SEAT('USERNAME');
CALL ENTRYLAYER.API.LIST_USERS();

Direct SQL seat management should come from a Snowflake role with ENTRYLAYER.ENTRYLAYER_ADMIN.

Billing boundary

Seat type drives EntryLayer paid-seat billing. It does not grant:

Snowflake database privileges
caller-rights source access
project can_read
field-group visibility
app role grants in Snowflake

Billing events are seat-oriented and should not include usernames, emails, table names, source row values, or business payloads.

Practical admin pattern

Most teams use seat types like this:

keep admin small
assign build only to people designing or configuring projects
use act for operators who work records
default everyone else to view until they need more capability
grant project access separately and intentionally