Data handling architecture

How EntryLayer handles customer data inside Snowflake

This is the canonical public reviewer URL for Snowflake Marketplace and customer security review. It shows where EntryLayer runs, where application state is stored, how customer source data is read, how approved work can be extracted, and which limited metadata can leave the customer account.

View architecture Review data boundary Security overview

Architecture diagram

Customer-account runtime, customer-account state.

EntryLayer is installed as a Snowflake Native App. The reviewed package supplies the service containers, while runtime behavior, application state, source reads, Cortex-assisted generation, and customer-controlled extraction happen through Snowflake-controlled surfaces.

Formless Logic provider boundary

Marketplace listing Install and commercial entry point

Reviewed app package Container images, manifest, setup SQL, and service spec

Support channel Customer-shared artifacts only

Customer installs reviewed package into Snowflake

Customer Snowflake account

Identity, runtime, source objects, app state, policy enforcement, and extraction stay customer controlled.

Users Snowflake users / Snowsight session

Admins, builders, submitters, reviewers, and automation operators authenticate through Snowflake.

Source data Customer source objects

Tables, views, and semantic views remain in customer-owned databases and schemas.

Governance Snowflake access policies

RBAC, object grants, masking policies, and row access policies remain authoritative.

EntryLayer Native App on SPCS

Web Web container

Serves the operator-facing EntryLayer interface through the Native App endpoint.

API API container

Handles project, workflow, source, Cortex, SQL API, and billing logic.

App state Snowflake Hybrid Tables

Projects, forms, submissions, memberships, audit history, access logs, and billing ledger rows.

Optional AI Snowflake Cortex

Metadata-assisted setup and form generation through Snowflake, not a provider-owned LLM endpoint.

Customer output Customer-controlled extraction

Approved submissions can flow into customer-owned tables, tasks, dbt models, BI, or ML workflows.

Anonymous seat-day and proration metadata only

Snowflake Marketplace billing

Billing events Billing month, seat days, days in month, monthly unit price cents, and calculation version. No customer content, usernames, emails, table names, row values, or query text.

Data boundary

What stays, what can leave, and what does not flow.

The zero-access posture is designed around Snowflake-managed runtime and customer-account storage. Normal product use does not require Formless Logic to host customer source data or receive business payloads.

Stays in customer Snowflake

Customer account data plane

Source rows remain in customer-owned tables, views, and semantic views.
Project state, submissions, memberships, access logs, workflow history, and billing ledger rows are stored in Snowflake Hybrid Tables.
Snowflake object grants, row access policies, masking policies, and customer roles remain authoritative for source access.

Can leave the account

Limited non-content surfaces

Snowflake Marketplace receives anonymous seat-day and proration metadata for billing.
Optional Snowflake event sharing remains optional and is not required for normal product use.
Support artifacts leave the account only when a customer intentionally shares them with Formless Logic.

Does not flow

No provider-side data path

No provider-owned external API is required for normal product behavior.
No EXTERNAL_ACCESS_INTEGRATION or NETWORK_RULE is used for provider-owned egress.
No provider-hosted source-data copy, external analytics database, or external LLM provider is required for normal use.

Data lifecycle

From source metadata to approved records.

EntryLayer avoids copying every source row into app storage up front. It uses metadata and customer-approved access to create the workflow, then materializes app-managed state only when workflow, local edits, or review history are needed.

Source metadata

Builders choose customer-owned Snowflake objects. EntryLayer uses metadata and customer grants to shape the project without copying the full source table.

Project and form design

Project metadata, drafts, field definitions, relationships, and published form versions are stored as app state in Hybrid Tables.

Virtual submissions

Source-backed rows can appear in EntryLayer work queues before a full local submission record exists.

Materialized submissions

When workflow, local edits, or review state is needed, EntryLayer creates app-managed submission state in Hybrid Tables.

Workflow and audit history

Approvals, field changes, access activity, comments, and review transitions remain queryable as app-managed Snowflake state.

Customer extraction

Customers can pull approved submission data into Snowflake-controlled downstream workflows with documented SQL surfaces.

Information flows

Reviewer-readable flow matrix.

These are the normal product flows to evaluate for Marketplace and customer review. Source data and application state are not copied to a provider-hosted SaaS database.

Source

Destination

Payload

Residency

Snowflake user / Snowsight session

EntryLayer web endpoint

Authenticated UI requests and operator actions

Customer Snowflake account runtime

Web container

API container

Internal application requests

SPCS service boundary

API container

Snowflake Hybrid Tables

Projects, form versions, submissions, memberships, access logs, workflow history, and billing ledger state

Customer Snowflake account

API container

Customer source objects

Metadata and caller-rights reads where supported by the source type

Customer Snowflake account

API container

Snowflake Cortex

Metadata-assisted generation requests when enabled

Snowflake service path

API container

Snowflake Marketplace billing

Anonymous seat-day and proration metadata only

Snowflake billing plane

Customer SQL workflows

Customer-owned downstream objects

Approved submissions through table functions or generated SQL

Customer Snowflake account

Components

Runtime components reviewers should inspect.

Snowflake Native App: Installed from Snowflake Marketplace and operated in the customer Snowflake account.
Snowpark Container Services: Runs the web and API containers supplied by the reviewed EntryLayer package.
Web container: Serves the EntryLayer React interface through the Native App endpoint.
API container: Handles project, workflow, access, source, Cortex, SQL API, and billing logic.
Hybrid Tables: Primary application state store for projects, forms, submissions, access, audit, and billing ledger data.
Restricted Caller Rights: Source reads use the signed-in user context where supported so Snowflake policy remains in force.
Snowflake Cortex: Optional metadata-assisted generation path through Snowflake, not a provider-owned LLM endpoint.
Marketplace billing: Receives anonymous seat-day billing metadata without source values, table names, query text, usernames, or emails.

Questionnaire answer

Architecture diagram URL for Snowflake review

Provide this page as the architecture and data-flow link in the Native Apps Security Questionnaire. For deeper implementation detail, use the supporting architecture, zero-access, Cortex, and data-lifecycle docs.

https://entrylayer.ai/security/architecture

Read architecture docs Zero-access posture Data lifecycle Cortex boundary