Virtual Submissions

When a project is connected to a Snowflake table, rows appear as virtual submissions. This is 42Forms’ lazy-loading approach to Snowflake data integration.

How It Works

1. Virtual rows are queried directly from the Snowflake source table via the caller connection
2. They appear in the submission list with negative IDs (the frontend uses id < 0 to identify them)
3. No local copy exists until a user edits the row
4. On first edit, the row is materialized: a local Submission record is created with all field values copied from Snowflake
5. Subsequent edits modify the local copy, with full audit trail (field history, status transitions)

Why Virtual?

• No data duplication: only edited rows are stored locally
• Real-time data: unedited rows always reflect the current Snowflake source
• Policy enforcement: row access and column masking policies are evaluated on every virtual row query via RCR

Tip

Virtual submissions use composite primary keys when the source table has a multi-column PK. Keys are joined with | (e.g., 430243|1 for an order line item).

Materialization

When a user edits a virtual submission:

1. The full row is fetched from Snowflake
2. A local Submission record is created with snowflake_row_key linking back to the source
3. SubmissionField records are created for every mapped column
4. The user’s edits are applied on top
5. Column masking detection marks fields that contain masked values

Materialization is idempotent: if two requests race to materialize the same row, the second one returns the existing local submission.