App & Data Lifecycle

Warehouse

Snowflake's word for a chunk of computing power (not storage).

Bigger = faster runs = higher cost per minute.

Source table

A table of input data transformed by the app's models. Lives in a shared or publisher database, maintained by Seek's Data & Analytics team (D&A) through data pipelines.

Output table

The result table an output model writes. Lives in the subscriber org's own apps database. An app may write one or more output tables; each exists once per org per variant.

Mapping table

The result table a mapping model writes. Exists once per subscriber org and is shared across variants and apps. The upcoming “App Model Reuse” feature will allow for sharing data across all subscribers.

Proxy role

A middleman Snowflake role between a source table and the apps that read it, so access survives when D&A rebuilds tables. Owned by D&A.

MTA

Multi-Tenant Architecture: all orgs share one Snowflake account; separation comes from roles and permissions, not separate accounts.

Model

One unit of an app's logic (Python or SQL). One model produces exactly one output table.

Wheel (.whl)

A packaged bundle of Python code, like a zip file, that SBT ships to the platform. Not necessary with SBT 1.0.

App Version

A bundle of source code, configuration, and metadata that defines a single version of an app. Currently comes in two flavors: AppModel and AppSpec.

AppModel

The legacy app implementation running in production today.

AppSpec

The SBT 1.0 replacement, rolling out now. Both will coexist for months during migration.

Parameters (params)

An input knob or filter an app exposes (like "how many days of history").

RLS params

Row-Level Security parameters. Limits set when an app is installed that control which slices of data (for example, which brands) that org can see.

Variant

One saved configuration of an app: parameter values (like lookback days) plus an optional run schedule. Each variant writes its own output table.

Publish

Making an app version available in the publisher org's catalog in Insight Cloud. It does NOT put the app in any org. Think "the book is now in the library," not "on your nightstand."

Install / Provision (an app)

Giving one specific org access to a published app. The book lands on your nightstand. Creates the org's app instance and default variant.

App listing

The App Store marketing page for an app (name, description, images, price). Separate from the app itself. Apps never need a listing to be installed.

Source mapping

The per-org record saying "this app's declared input = this actual Snowflake table."

Sync Engine

The control loop that keeps Snowflake and Sigma continuously matching what Insight Cloud says should be true. See The Sync Engine.

Stage (Tool)

Owner

What happens

0. Org & publisher setup

(Insight Cloud)

Customer Success or D&A

A Seek employee creates the org. The Sync Engine derives and creates the org's Snowflake service user, databases, roles, and warehouses within seconds (MTA provisioning). Publisher orgs get a Publisher section and complete a Publisher Profile.

1. Source data lands

(Prefect + Snowflake)

D&A Data Engineers

Pipelines (automated data-loading jobs, run by a scheduler called Prefect) load and refresh source tables. D&A keeps a proxy role with read access to each.

2. App is built

(Python + SBT)

D&A Data Scientists

DS writes and tests models, then defines the app spec: models, sources, params, packages, and the Sigma workbook id. Local runs write _test tables so they cannot collide with production.

3. Data model & workbook

(Sigma)

D&A (DS, then BI Developer)

DS builds the Sigma data model with user attributes so one model serves every variant. A BI Developer builds the workbook. The workbook id goes into the app spec.

4. Upload & publish

(SBT CLI)

D&A Data Scientists

sbt build-app returns a version; sbt publish-app makes it the catalog default. Ready to be installed into any organization, but installed nowhere yet. (App Store availability is separate: it applies only to apps a publisher chooses to list.)

5. Install into a subscriber org

(Insight Cloud)

Seek staff today; Marketplace flow later

Grant the app (also triggered by a purchase), set RLS params if used. IC creates the app instance, a default variant, and the Prefect schedule plumbing. Declared sources resolve to real tables via source mappings.

6. Access granted automatically

(Sync Engine)

Platform (engine); D&A (proxy roles)

The engine grants proxy roles to the org's app-runner role and pre-creates Sigma service users and workbook access per variant.

7. App runs

(Prefect → Snowflake)

Automatic

Runs as the org's service user, reads sources through proxy roles, writes outputs to the org's apps database.

8. Subscriber views the app

(Insight Cloud)

Customer Success supports

IC builds a Sigma embed that loads the right variant's output with the right role and warehouse. Access mirrors IC roles.