EntryLayer is designed to stay close to governed Snowflake data instead of copying source rows into a vendor-hosted stack first. The app turns Snowflake-backed rows into project workspaces, forms, workflow, review, and audit history while keeping Snowflake as the main data and governance boundary.
Customer Snowflake account
Installed EntryLayer Native App
api container -> business logic, SQL API dispatch, source metadata, Cortex orchestration
web container -> React app, form builder, record workspace, admin surfaces
Hybrid Tables -> projects, drafts, submissions, memberships, audit, billing state
tables/views/semantic views -> source records and source metadata
caller rights grants -> Snowflake-enforced access boundary
Cortex -> supported AI-assisted form/rule generation
Marketplace -> seat-oriented billing events
Component Technology Purpose API container FastAPI Business logic, auth context, SQL API RPC dispatch, source access, AI orchestration. Web container React + TypeScript Project workspace, form builder, submission detail, admin settings. Application storage Snowflake Hybrid Tables Projects, form versions, submissions, memberships, permissions, audit history, billing ledger. Source data Customer Snowflake objects Tables, views, and semantic views that projects can use as source objects. AI surface Snowflake Cortex Form generation and rule assistance within Snowflake-native boundaries. Compute Snowpark Container Services Runs the API and web containers in the installed app.
Area Owner/control point Notes Installed app objects EntryLayer app package Created during install or upgrade through the Native App setup script. Application state Stored by EntryLayer in the customer Snowflake account Lives in Hybrid Tables inside the installed app namespace. Source databases and schemas Customer EntryLayer can only use what the customer grants. Source row governance Snowflake/customer policies Row access, masking, and object grants are enforced by Snowflake. App users and seats Customer admin through UI or SQL API Seat type controls product capability, not automatic record visibility. Project access EntryLayer project permissions Determines can_read, can_edit, can_manage, and related project permissions.
A customer installs the Native App and grants required app permissions.
An admin configures EntryLayer seats, source access, and project access.
Builders create projects from Snowflake tables, views, semantic views, or empty forms.
Source-connected projects use metadata to build form layout and field definitions.
Users work records through the web app; virtual source rows materialize only when workflow or local state is needed.
App-managed state, audit history, and workflow data stay in Hybrid Tables.
EntryLayer uses Snowflake governance instead of replacing it with an app-local substitute.
Governance layer What it controls Snowflake object grants Which source databases, schemas, tables, views, or semantic views the app can describe or query. Restricted Caller Rights Lets source access run with the signed-in user’s Snowflake privileges where supported. Row access policies Which source rows are visible to the signed-in user. Masking policies Which source values are visible or masked for the signed-in user. EntryLayer project permissions Which app records, fields, and management surfaces a user can use.
EntryLayer avoids copying every source row into app-managed storage up front.
Strategy Why it matters Virtual submissions Source rows can appear in work queues before app submissions exist. Materialization on need Local submission state is created only when workflow or local edit state is required. Combined API payloads Main pages can load project context, permissions, and form metadata efficiently. Hybrid Tables App state and audit records stay close to the Snowflake runtime.
