Row Access Policies in Snowflake
How Row Access Policies Work in Snowflake (And Why We Use Them)
When we need to control who sees what rows in a Snowflake table, we use Row Access Policies.
Unlike column-level masking, which hides sensitive fields, row access policies filter entire rows based on user attributes like roles or session variables.
Row access policy
A row access policy is a Snowflake object that acts as a dynamic filter applied whenever someone queries a table or view.
- It behaves like an automatic WHERE clause
- It filters rows based on the current user or session
- It applies during query time (not at data load time)
- It works with SELECT, COPY INTO, and other operations
Creating a Row Access Policy
We typically follow three steps:
- Create the policy using CREATE ROW ACCESS POLICY
- Attach it to a table or view
- Let Snowflake evaluate it every time the object is queried
Example: Show Region-Specific Rows Only
Let’s say we have a sales table with a region column. We want users to only see data for their assigned region.
Step 1: Define the policy
Step 2: Attach it to the table
Now, if someone in the US region runs a query, they’ll only see rows where region = 'US'.
How this is handled behind the scenes
Snowflake rewrites the query under the hood using the policy logic. It doesn’t alter the table data itself.
Testing the Policy
Before deploying a policy to production, test it like this:
- Set the session context (ALTER SESSION)
- Run queries with different roles or users
- Validate visibility of expected rows
Can You Apply Multiple Policies?
Snowflake supports only one row access policy per table or view.
To implement more complex rules, you’ll need to:
- Use logical operators inside a single policy
- Check for multiple roles using IS_ROLE_IN_SESSION()
- Apply CASE logic within the policy expression
Combining Row Access and Column Masking
We can use both together for layered security:
Row access controls which rows are shown
Column masking hides or transforms certain fields in those rows
Managing and Auditing Policies
Some helpful commands and tools:
- View all policies: SHOW ROW ACCESS POLICIES
- See policy definitions: Query INFORMATION_SCHEMA.ROW_ACCESS_POLICIES
- Remove a policy from a table: ALTER TABLE sales DROP ROW ACCESS POLICY;
- Name your policies clearly, especially if you plan to version them (e.g., policy_sales_v1)
Useful Snowflake Functions
| Function | What it does |
| CURRENT_USER() | Returns the current user |
| CURRENT_ROLE() | Returns the current role |
| IS_ROLE_IN_SESSION() | Checks if a role is active |
| CURRENT_REGION() | Custom or session-based region |
| SESSION_USER() | Returns the session’s authenticated user |
These functions help make policies more flexible and context-aware.
How Row Access Differs from Column Masking
| Feature | Row Access Policy | Column Masking |
| Filters | Whole rows | Specific columns |
| Use case | Limit access by geography, department, etc. | Hide sensitive fields like SSNs |
| Based on | User, role, session context | User, role, session context |
| Can combine | Yes | Yes |
Use row access when what a user can see depends on where they belong (e.g., region or department).
Use column masking when what fields a user can see depends on their level of clearance.
Row Access Policy vs Column masking
- Use Row Access policy to limit /filter data based on certain condition. use column masking to hide sensitive fields.
- For Example - use Row Access policy to limit access by geography, department, etc. meanwhile use column masking to hide sensitive fields like SSNs, IDs
Conclusion
Row Access Policies help us control visibility at the row level. They’re easy to set up and flexible enough for complex scenarios.
We’ve used them to build region-specific dashboards, protect internal data by team, and support secure self-service reporting — all without duplicating data.
When used together with column masking and access control, they give us a clean way to manage security at scale.