Prepare data access for metrics

Preview Building metrics goes faster when the access is in place before the first run. Use this page to ask your warehouse and BI admins for the right grants, and to answer your security team’s questions about what is read and what is stored. The short version: your own agent, on your computer, reads your query history and BI models with access you give it. Metric Studio never connects to your warehouse and never runs SQL. What reaches Atlan Trident is only what you approve: metric definitions, saved queries, and the links between them.

What to ask for

A missing permission doesn’t stop a build. The agent reads everything it can, tells you what it couldn’t read, and names whom to ask.

Query history

Query history is the SQL your team already runs, and it is usually the richest source of metrics. Your agent reads up to the last 90 days of successful SELECT statements that touch the tables in scope, grouped by distinct statement, up to 5,000 statements.

Snowflake

The agent tries these in order and uses the first one that answers.

1. A query-shape view an admin created once. This is the easiest option to approve: analysts need only SELECT on one view, and the view holds no user names. An admin who can read SNOWFLAKE.ACCOUNT_USAGE runs this, narrowing database_name to the databases your team works in:
   create schema if not exists <db>.atlan;
   create or replace secure view <db>.atlan.query_shapes as
   select query_text as sql, count(*) as exec, count(distinct user_name) as users,
          max(start_time) as last_run
   from snowflake.account_usage.query_history
   where execution_status = 'SUCCESS' and query_type = 'SELECT'
     and start_time >= dateadd('day', -90, current_timestamp())
     and database_name in ('<DB>')
   group by query_text;
   grant usage on schema <db>.atlan to role <analyst_role>;
   grant select on view <db>.atlan.query_shapes to role <analyst_role>;
   
2. SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY, when your role has the SNOWFLAKE.GOVERNANCE_VIEWER database role or imported privileges on the SNOWFLAKE database.
3. INFORMATION_SCHEMA.QUERY_HISTORY, which needs no grant. It returns only your own queries, and others’ on warehouses your role can monitor, from the last 7 days. If your build found only a week of history, this is why: ask for option 1 or 2.
4. An export file from someone who has access.

Databricks

1. A query-shape view an admin created once, as for Snowflake:
   create schema if not exists <catalog>.atlan;
   create or replace view <catalog>.atlan.query_shapes as
   select statement_text as sql, count(*) as exec, count(distinct executed_by_user_id) as users,
          max(start_time) as last_run
   from system.query.history
   where execution_status = 'FINISHED' and statement_type = 'SELECT'
     and start_time >= current_timestamp() - interval 90 days
   group by statement_text;
   grant use schema on schema <catalog>.atlan to `<analyst_group>`;
   grant select on view <catalog>.atlan.query_shapes to `<analyst_group>`;
   
2. system.query.history, when you can read system tables.
3. The Query History API, which returns the queries you can see on the Query History page.
4. An export file from someone who has access.

Other warehouses

Your agent uses the warehouse’s own read-only query history. If there isn’t one, ask for an export.

What stays on your computer

The agent works in a project folder on your computer. The query history it reads, the BI files it downloads, and the results of the SQL it runs to check a metric stay there. Before anything is written to a metric or a saved query, the agent cleans what it took from query history:

• User names are counted, never written. A saved query records how many people ran it, not who.
• Values that look like personal data are replaced. A literal such as an email address in a WHERE clause becomes a numbered placeholder, <redacted:1>, so the SQL still reads correctly without the value.
• Rare values are left out. By default, a literal is kept only when several statements or several people use it.

What Atlan Trident stores

When you approve a write, Atlan Trident stores:

• Metrics: each definition, including its formula, source table, joins, filters, grain, dimensions, and example questions with SQL.
• Saved queries: the SQL, the question it answers, and how often and by how many people it ran.
• Links between metrics and the saved queries that use them, and the revision and release history of each.

It doesn’t store your table rows: Metric Studio never connects to your warehouse. Atlan Trident runs on AWS in US East (N. Virginia). See Where Atlan Trident runs. If your agent sessions are traced, what a trace keeps is set separately. See Manage trace privacy.

Before you can use real data

If your security team hasn’t approved using real data yet, you can still see the whole flow:

• Try the demo. The Analytics plugin builds metrics on sample data and needs no warehouse and no sign-in.
• Keep it local. On your own data, choose Keep local at the save step. Nothing is written to Atlan Trident until you choose to save.

Related

• Build your first metrics: Build metrics from query history once access is in place.
• Set up Analytics in your coding agent: Build from dashboards, BI models and query history.
• Metric Studio errors: When a build doesn’t start or finds too little.