Start with the access-control chain
Authenticates and activates an account role.
Receives privileges directly or through inheritance.
Allows a defined action on a securable object.
Warehouse, database, schema, table, view or another resource.
Snowflake combines discretionary access control through object ownership, role-based access control through roles, and supported user-based grants. For normal organizational access, Snowflake recommends privileges through roles rather than repeated direct grants to individual users.
What may be done? Privilege. Who receives the permission set? Role. Who controls the object? Owner role. What applies to later objects? Future grant.
Role hierarchy: privileges flow upward to grantee roles
Granting one role to another creates inheritance. If SALES_READ is granted to SALES_ANALYST, the higher SALES_ANALYST role inherits the lower role’s privileges. Granting SALES_ANALYST to a user makes the inherited access available when that account role is active.
SALES_READ
USAGE on database and schema, SELECT on approved tables.
SALES_ANALYST
Inherits SALES_READ and adds business-function access.
SYSADMIN
Can inherit custom roles when the hierarchy is connected as recommended.
A role’s owner does not automatically inherit the privileges of the role it owns. Inheritance comes from the grant hierarchy. Connect custom roles appropriately so objects do not become manageable only by isolated owners or MANAGE GRANTS holders.
Object access requires every container privilege in the path
Reading a table normally requires more than SELECT on the table. The active role needs access through its containers and compute:
Privileges are object-specific. ALL PRIVILEGES means all applicable privileges on the referenced object type, not unlimited authority across the entire account. Use least-privilege object and access roles aligned with business functions.
OWNERSHIP is powerful and singular
Each securable object is owned by one role. In a regular schema, the object owner controls the object and can normally grant privileges on it. Transferring ownership changes that authority and requires careful handling of existing grants.
- The role active when an object is created normally becomes its owner.
- Ownership is not the same as a role being granted to another role.
- Account-management system roles should not become the default home for every application privilege.
- Use purpose-built owner and access roles to separate administration from consumption.
- Remember that ACCOUNTADMIN is powerful but is not an automatic superuser for every isolated object hierarchy.
Future grants cover new objects, not existing ones
A future grant defines permissions that Snowflake applies when matching objects are created later. It prevents repeated manual grants as schemas evolve, but it does not retroactively fix access to current objects.
Existing objects
Use grants on individual objects or ON ALL TABLES IN SCHEMA for the current set.
New objects
Use ON FUTURE TABLES IN SCHEMA to establish the initial privilege when each table appears.
Complete pattern
Apply both existing-object and future-object grants when a role needs present and continuing access.
If database-level and schema-level future grants exist for the same object type in one database, schema-level future grants take precedence and the database-level grants for that object type are ignored in that schema. Inspect the actual future grant definitions rather than assuming they combine.
Managed access schemas centralize grant decisions
In a managed access schema, individual object owners lose the ability to decide grants. The schema owner or a role with the global MANAGE GRANTS privilege controls grants on current and future objects. This supports centralized governance but changes who can resolve permission requests.
A table owner tries to grant SELECT inside a managed access schema and receives an authorization failure. Use the schema owner or an appropriately governed role with MANAGE GRANTS instead of transferring table ownership merely to work around the control.
Worked scenario: yesterday’s table works, today’s table fails
Situation: An analyst can query existing tables in ANALYTICS.REPORTING. A pipeline creates DAILY_SALES, but the same query role receives insufficient privileges on the new table.
The role has current-object grants but no effective future grant
Existing access: SELECT was granted on all tables that existed during setup.
New object: DAILY_SALES was created later and received no SELECT grant.
Check: inspect future grants at schema and database levels.
Fix: authorized grant administrator adds the correct future grant and grants access to the new existing table.
Also verify that the active role inherits the intended access role and has USAGE on the warehouse, database and schema. A future SELECT grant cannot replace missing container or warehouse access.
Systematic “insufficient privileges” troubleshooting
- Confirm session context: check
CURRENT_USER(),CURRENT_ROLE()and active secondary roles. - Identify the exact action: separate warehouse usage, object lookup, SELECT, CREATE, ownership and grant operations.
- Trace role assignments: inspect which account roles the user has and which lower roles they inherit.
- Trace object path: verify warehouse, database, schema and target-object privileges.
- Inspect grants: use
SHOW GRANTS TO ROLE,SHOW GRANTS ONand relevant account-usage views where available. - Check object identity: verify database, schema, quoted identifier and whether a view references protected underlying objects.
- Check ownership model: determine the owner role and whether the schema is managed access.
- Check timing: distinguish existing objects from future-grant coverage and recent changes.
- Test least privilege: grant only the missing capability through the intended role hierarchy, then retest.
Avoid solving access errors by switching permanently to ACCOUNTADMIN or granting broad privileges. That hides the broken access model and expands risk.
SnowPro Core practice checks with explanations
A role has SELECT on a table but no USAGE on its schema. Can it query the table?
No. The role needs the required privileges through the object hierarchy, including schema and database access, plus warehouse usage to execute the query.
A future SELECT grant is added today. Does it grant SELECT on tables created yesterday?
No. Grant existing tables separately; the future grant applies when later matching tables are created.
Who can grant access to a table in a managed access schema?
The managed schema owner or a role with MANAGE GRANTS, not the individual table owner acting solely through object ownership.
A database role contains the right privileges. Can a user activate it directly?
No. Grant the database role to an account role, then grant and activate that account role.
Common SnowPro Core mistakes
- Reversing the direction of role inheritance.
- Assuming role ownership causes privilege inheritance.
- Granting SELECT without USAGE on database and schema.
- Expecting future grants to cover existing objects.
- Ignoring schema-level precedence over database-level future grants.
- Trying to activate a database role directly.
- Letting isolated custom roles own objects outside the intended hierarchy.
- Using ACCOUNTADMIN for routine data access.
- Ignoring managed-access grant authority.
Frequently asked questions
How do Snowflake users normally receive privileges?
Privileges are usually granted to roles, and roles are granted to users or higher roles. This role-based model makes business-function access easier to manage than repeated direct user grants.
Which direction does privilege inheritance flow in a Snowflake role hierarchy?
A higher role inherits privileges from roles granted to it. If ANALYST_READ is granted to ANALYST, ANALYST inherits the privileges held by ANALYST_READ.
Do future grants give access to existing tables?
No. Future grants automatically apply the defined privileges to matching objects created later. Existing objects require grants on individual objects or an ALL grant for the current objects.
Who can grant privileges in a managed access schema?
Grant decisions are centralized. The schema owner or a role with the global MANAGE GRANTS privilege can grant privileges, including future grants; individual object owners cannot independently make those grant decisions.
Can a Snowflake database role be activated directly?
No. A database role is limited to its database and must be granted to an account role. The account role can then be activated in a session.
Official Snowflake references
Review Snowflake documentation for the access-control overview, access-control best practices, GRANT and future-grant behavior, SHOW GRANTS, and the SnowPro Core COF-C03 certification. Verify current feature behavior for your account.