Virtual Submissions

When a project is connected to a Snowflake source, rows can appear in EntryLayer before a local submission record exists for them. EntryLayer calls these rows virtual submissions.

When this matters

Use this page when:

a source-connected project shows records that have not been edited yet
workflow-enabled projects show not_started
you need to explain why app audit history starts after materialization
a data platform or security team asks whether source rows are copied immediately

Lifecycle diagram

Customer source row
  -> visible through Snowflake grants/policies
  -> virtual submission in EntryLayer list
  -> user action needs local workflow/edit state
  -> materialized submission in Hybrid Tables
  -> workflow history, field history, access history, audit state

What users see

Virtual submissions show up in normal project workflows:

in the project submission list
in project counts and overview surfaces
as openable records in the submission detail experience

In workflow-enabled source-connected projects, untouched virtual rows can appear with the status not_started.

That status means:

the row is visible from the Snowflake source
no local managed submission exists yet
local workflow tracking has not started yet

Virtual vs materialized behavior

Behavior	Virtual submission	Materialized submission
Source of record	Customer Snowflake source object	EntryLayer app-managed submission state
App-managed audit trail	Not full local history yet	Workflow, field, and access history are tracked
Source access	Snowflake row access and masking policies apply	App project permissions and stored local state apply; source access can still matter for source-backed context
Storage impact	No full local submission copy up front	Stored in Hybrid Tables inside the installed app namespace
Typical status	`not_started` for workflow-enabled untouched rows	Normal workflow states after local work begins

Materialization

Materialization turns a virtual row into a managed EntryLayer submission.

When EntryLayer materializes a row, it:

reads the source values needed for the action through the approved source access path
creates the managed submission record
applies the user’s local edit or workflow-triggering action
begins tracking local audit history, workflow state, and managed field changes

After materialization, later edits work against the managed submission rather than an untouched virtual row.

Access-control caveats

Virtual submissions are bounded by both Snowflake and EntryLayer controls:

Boundary	What to remember
Object grants	The app cannot use source objects the customer has not granted.
Row access policies	Users can see different virtual rows depending on Snowflake policy results.
Masking policies	Source values can remain masked according to the signed-in user’s Snowflake context.
Project permissions	A visible project shell does not automatically mean the user can read records.
Field groups	App-managed field-group settings can still hide or lock fields in the EntryLayer UI.

Relationship to workflow

If workflow is enabled:

virtual source rows can appear as not_started
once a row is materialized, the normal submission lifecycle begins
persisted workflow states follow the configured workflow model
publish and form-design changes affect user-visible behavior only after the draft is published