Permissions & Grants

Data Prep needs three things to be in place: the feature enabled for your workspace, the right permissions on your account, and one extra grant in your warehouse.

Enabling the feature

Data Prep is a per-workspace entitlement, and it is off by default. A Zeotap platform administrator turns it on for a workspace; it cannot be turned on from workspace settings.

That is deliberate, because enabling it asks something of you rather than only of Zeotap: Zeotap starts creating and rebuilding long-lived tables in your warehouse, in a schema it does not yet have access to. The grant below is what you are being asked for, and the connection test only starts asking for it once the feature is enabled — so no existing warehouse connection’s test changes until the moment somebody is meant to act on it.

Until it is enabled, Data Prep does not appear in the sidebar and nothing creates or reads the cdp_prep schema.

If it is turned off again

Revoking the entitlement stops scheduling, building and editing. It never drops a table.

Your prepared tables stay exactly where they are, with their data. A model over one goes on serving audiences and syncs from the last build it received, and the UI says the table is no longer refreshing rather than pretending it is. Dropping the tables is a separate, explicit act — deleting the prepared table.

You can still dematerialize a model that was materialized onto a prepared table, so a model can always be moved back off a table that has stopped refreshing.

Permissions

Owners and admins hold all three. Members can view.

Run builds is also available as a scope on a REST API key, which is what lets an orchestrator you already run start a build when data lands. See Triggers & Freshness.

Creating a model over a prepared table additionally needs permission to create models; applying a blueprint needs both, since it creates prepared tables, models and relationships together.

Warehouse grants

Zeotap builds prepared tables into one schema, cdp_prep, alongside the operational schemas it already manages — and only into that schema. Every statement that creates or changes a table is generated by Zeotap from your recipe; a recipe step is always a SELECT and can never write anywhere.

Grant create, insert, update and delete on that one schema, plus whatever your warehouse needs to swap a table in. The exact statements are on your warehouse’s page:

• Snowflake — the schema is CDP_PREP, uppercase and unquoted, and the atomic swap a full rebuild ends with needs ownership of the tables as well
• BigQuery
• Databricks
• ClickHouse
• Redshift

Checking the grants

Run a connection test on the warehouse. An entitled workspace’s test carries one extra step, write_prep, which creates, writes to and drops a scratch table in cdp_prep.

It is the only conditional step in the list — so a write_prep failure on a warehouse whose test has always passed means the entitlement was granted since it last ran, not that something regressed. See Testing Connections.

Personal data

Prepared tables sit inside Zeotap’s existing column sensitivity and masking rules, with one addition: an output column’s sensitivity is inherited from the columns it was built from. Where the lineage is exact — which it is for a recipe of typed steps — the inheritance is exact. Where a hand-written SQL step sits on a column’s path, Zeotap cannot prove what the column came from, so it treats it as unverified and masks it rather than assuming it is clean.

That applies to previews, to profiles, and to anything Zeotap Agent is shown. A profile’s masking is re-applied every time a stored profile is read, so marking a column sensitive takes effect on the next read rather than when the stored result expires.

What the inheritance is built from. A column is known to hold personal data in exactly two ways: a profile of the input measured it (email or phone values above the threshold), or a model already defined over the same physical table declares it sensitive. Lineage then carries that verdict forward through the recipe.

And a measured backstop, in previews. Because lineage can only carry a verdict that exists, a preview measures its own rows as well. After lineage has been applied, a column is redacted when all three of these hold:

1. lineage gave it no sensitivity at all;
2. its declared warehouse type is text; and
3. Zeotap’s own email or phone pattern matches at least half of the non-empty values among the rows on screen (at most 500).

A verdict from lineage is never overwritten — it knows where a column came from, where a sample only knows what it looks like today. Numeric, boolean, timestamp and JSON columns are never masked this way, so a column of order ids cannot be caught by a phone pattern that matches a run of digits. And the measurement is never stored: one sample of one preview is not a fact about a table, so it does not change the prepared table’s recorded columns.

So profiling is no longer a precondition for email- and phone-shaped columns — those are masked in a preview with no profile at all. It remains the way every other kind of personal data gets a verdict: a name, a postal address or a date of birth has no pattern reliable enough to fire on, so profiling the input, or a model over it marking the column sensitive, is what makes Zeotap aware of it.

Creating a model from a prepared table pre-fills the model’s column configuration from that inheritance, so the sensitivity you set on a raw column follows the data through.

Audit

Creating, editing, deleting and building a prepared table through the app or the REST API are recorded in the workspace audit log, as is applying a blueprint. What Zeotap Agent does through its own tools is recorded in the AI Audit Log instead, against the resource it actually created — and a prepared table the agent made is marked as its work on the list and on its own page.

Next steps

• Overview
• Testing Connections
• FAQ