> For the complete documentation index, see [llms.txt](https://documentation.immuta.com/saas/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.immuta.com/saas/configuration/integrations/snowflake/reference-guides/snowflake-overview/accessing-data.md).
# Accessing Data
{% hint style="info" %}
**New connections**
The [new connections flow](/saas/configuration/integrations/data-and-integrations/registering-a-connection/reference-guides/new-connections-reference-guide.md) documented here is available and released to select tenants.
{% endhint %}
Once data is registered through the Snowflake connection, you will access your data through your Snowflake queries as you normally would. If you are subscribed to the data source, Immuta grants you access to the data in Snowflake.
When you submit a query, the Snowflake client submits the SQL query to the Snowflake server, which then processes the query and determines what data your role is allowed to see. Then, the Snowflake server queries the database and returns the query results to the Snowflake client, which then returns policy-enforced data to you.
The diagram below illustrates how Immuta, the Snowflake server, and Snowflake client interact to access data.
## Querying data
Because subscription policies are managed through roles, you must be acting under the role Immuta creates for you to get access to your subscribed data sources. When querying data in Snowflake, do one of the following:
* [Use the role](https://docs.snowflake.com/en/sql-reference/sql/use-role.html#syntax) that Immuta creates and manages. (For example, `USE ROLE _USER_`: The role prefix is set on the [Immuta app settings page](/saas/configuration/application-configuration/how-to-guides/config-builder-guide.md#integration-settings) and the `` is your Immuta username.) If the current active primary role is used to query tables, `USAGE` on a Snowflake warehouse must be granted to the Immuta-managed Snowflake role for each user.
* Set your Snowflake to use secondary roles ([`USE SECONDARY ROLES ALL`](https://docs.snowflake.com/en/sql-reference/sql/use-secondary-roles.html#syntax)), which allows users to use the privileges from all roles that they have been granted, including `_USER_`, in addition to the current active primary role. Users may also set a value for `DEFAULT_SECONDARY_ROLES` as an [object property](https://docs.snowflake.com/en/sql-reference/sql/create-user.html#optional-object-properties-objectproperties) on a Snowflake user. To learn more about primary roles and secondary roles in Snowflake, see [Snowflake documentation](https://docs.snowflake.com/en/user-guide/security-access-control-overview.html#enforcement-model-the-primary-role-and-secondary-roles).
## User impersonation
Impersonation allows Immuta users or system accounts to query data sources they are subscribed to as another Immuta user.
Consider the following users and their data source subscriptions.
**User 1 data source subscriptions**
* HR data source
* Research data source
**User 2 data source subscriptions**
* HR data source
* Consumer report data source
The table below illustrates what data is returned when User 1, User 2, and User 2 impersonating User 1 query these data sources.
| | HR data source | Research data source | Consumer report data source |
| ------------------------------- | ----------------------- | ---------------------------------------------- | --------------------------- |
| **User 1** | `name` column is masked | `ssn` column is masked with hashing | :x: Denied access |
| **User 2** | All data visible | :x: Denied access | `address` column is masked |
| **User 2 impersonating User 1** | `name` column is masked | :x: [Denied access](#user-content-fn-1)[^1] | `address` column is masked |
Users with the `APPLICATION_ADMIN` Immuta permission can enable impersonation when [registering a Snowflake connection](/saas/configuration/integrations/snowflake/how-to-guides/connect-snowflake.md) for the first time or [edit an existing connection](/saas/configuration/integrations/snowflake/how-to-guides/manage-snowflake-connection-settings.md#edit-the-policy-settings) to enable impersonation.
#### Audit
Snowflake query audit will show the user running the queries as the user logged in to Snowflake, **not** as the user they are impersonating.
[^1]: Even though they are impersonating a user who is subscribed to the data source, User 2 will be denied access to the data because they are not subscribed to the data source.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://documentation.immuta.com/saas/configuration/integrations/snowflake/reference-guides/snowflake-overview/accessing-data.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.