Sources

Add each Snowflake database you want Zeotap to read from as a source. The form generates a GRANT script you run once in Snowsight, and Zeotap then queries the database through the warehouse you bound at install. There are no credentials to manage — the grants are scoped to the application identity.

Adding a Snowflake source

Navigate to Sources in the Zeotap sidebar and click Add source → Snowflake. The form asks for:

When you fill in the database (and optional schema) field, the form renders a SQL snippet for you to copy and run in Snowsight as ACCOUNTADMIN, or as the role that owns the database.

-- Run as ACCOUNTADMIN (or the role that owns <DATABASE>).
-- Re-run this script whenever you add new schemas/tables you
-- want the app to read — Snowflake forbids GRANT ... ON FUTURE
-- ... TO APPLICATION, so future objects need an explicit re-grant.
GRANT USAGE         ON DATABASE <DATABASE> TO APPLICATION zeotap;
GRANT CREATE SCHEMA ON DATABASE <DATABASE> TO APPLICATION zeotap;
GRANT USAGE  ON ALL SCHEMAS IN DATABASE <DATABASE> TO APPLICATION zeotap;
GRANT SELECT ON ALL TABLES  IN DATABASE <DATABASE> TO APPLICATION zeotap;
GRANT SELECT ON ALL VIEWS   IN DATABASE <DATABASE> TO APPLICATION zeotap;

If you specified a schema, the script narrows the table and view grants to that schema instead of the whole database:

GRANT USAGE  ON SCHEMA <DATABASE>.<SCHEMA>            TO APPLICATION zeotap;
GRANT SELECT ON ALL TABLES IN SCHEMA <DATABASE>.<SCHEMA> TO APPLICATION zeotap;
GRANT SELECT ON ALL VIEWS  IN SCHEMA <DATABASE>.<SCHEMA> TO APPLICATION zeotap;

After the script runs, click Test connection in the form. The control plane runs SELECT 1 against the bound database through the application’s identity. A 200 response means the grants landed correctly. Click Save to register the source.

Why these grants

• USAGE on the database and USAGE ON ALL SCHEMAS — needed for Zeotap to discover schemas and select the right context.
• SELECT ON ALL TABLES and ON ALL VIEWS — Zeotap only reads from sources. It never writes, modifies, or drops tables in the bound database. The granted privilege set is read-only by construction.
• CREATE SCHEMA on the database — Zeotap needs to create CDP_PLANNER and CDP_AUDIT for sync orchestration and run-state writes. These two schemas hold the plan tables (a/b slot rotation for diff-based CDC) and audit tables; they don’t touch your existing schemas.

The application identity has no privileges on any other database in your account. If you grant Zeotap access to ANALYTICS, it can read every schema in ANALYTICS and write to ANALYTICS.CDP_PLANNER / ANALYTICS.CDP_AUDIT, but it cannot reach MARKETING, RAW, or any other database you didn’t grant.

Why no future grants

You’ll notice the script omits GRANT ... ON FUTURE TABLES and GRANT ... ON FUTURE SCHEMAS. Snowflake explicitly rejects future grants to applications:

Future grant on objects of type SCHEMA to APPLICATION is restricted

The reasoning is that applications are transient identities — they can be uninstalled and reinstalled, and Snowflake doesn’t want orphaned future-grant rules tied to non-existent application objects. The practical consequence is that whenever you add a new schema or table you want Zeotap to read, you have to re-run the GRANT block.

The simplest workflow is:

1. Bookmark the GRANT script the UI generated when you added the source.
2. Whenever you add a new schema or table to the source database, re-run the script. CREATE OR REPLACE semantics on GRANT make it idempotent — re-running over already-granted objects is a no-op.

For databases with frequent schema additions, you can wrap the GRANT block in a Snowflake task that runs every hour or every day. The grants are idempotent and cheap to repeat.

Editing or removing a source

Click the source’s name in the Sources list and choose Edit to change the database, schema, or display name. Changing the database invalidates the existing grants — re-run the GRANT block against the new database.

Choose Delete to remove the source. Zeotap warns you if any models, audiences, or syncs still reference the source. Deletion is metadata-only — the application doesn’t issue REVOKE against your database. To fully revoke access, run:

REVOKE ALL ON DATABASE <DATABASE> FROM APPLICATION zeotap;
REVOKE ALL ON ALL SCHEMAS IN DATABASE <DATABASE> FROM APPLICATION zeotap;
REVOKE ALL ON ALL TABLES IN DATABASE <DATABASE> FROM APPLICATION zeotap;
REVOKE ALL ON ALL VIEWS IN DATABASE <DATABASE> FROM APPLICATION zeotap;

See also

• Warehouses — high-level overview of how Warehouse connections work in Zeotap.
• Snowflake Warehouse — the same source type for cloud customers; the field set is the same minus the GRANT block.
• Models — SQL models that select from your sources.