Access & Permission Issues

Access problems in Casabase Cube can originate at several different layers.

The most important first step is to identify what the user cannot access:

Cannot Access the Application
            │
            ▼
Snowflake / Native App Access


Can Access the Application,
but Cannot Administer It
            │
            ▼
Application Role


Cannot Read Source Objects
            │
            ▼
Privileges Granted to the Application


Can Query the Cube,
but Data Is Restricted
            │
            ▼
Casabase Cube Row-Level Security

These controls are related, but they are not interchangeable.

Application Roles

Casabase Cube provides two primary application roles:

Application Role	Purpose
CUBE_PUBLIC	Query and discovery access.
CUBE_ADMIN	Modeling and administrative access. Inherits CUBE_PUBLIC.

A user who only needs to query cubes generally requires CUBE_PUBLIC.

A user who needs to create or rebuild dimensions, manage formulas, configure security, schedule queries, or perform other administrative operations requires CUBE_ADMIN.

Because CUBE_ADMIN inherits CUBE_PUBLIC, an administrator does not need both roles granted separately.

Grant Query Access

Assuming the Native App is installed as CASABASE_CUBE, a Snowflake administrator can grant query access to an account role:

GRANT APPLICATION ROLE CASABASE_CUBE.CUBE_PUBLIC
TO ROLE ANALYST;

Users assigned the ANALYST Snowflake role can then use the capabilities exposed through CUBE_PUBLIC.

Substitute your installed application name and Snowflake role as appropriate.

Grant Administrative Access

To grant administrative capabilities:

GRANT APPLICATION ROLE CASABASE_CUBE.CUBE_ADMIN
TO ROLE CUBE_ADMINISTRATOR;

Use administrative access only for users who require it.

See Roles and Privileges.

Verify Application-Role Grants

To review grants for the application roles:

SHOW GRANTS OF APPLICATION ROLE CASABASE_CUBE.CUBE_PUBLIC;

and:

SHOW GRANTS OF APPLICATION ROLE CASABASE_CUBE.CUBE_ADMIN;

When a user can open Casabase Cube but cannot perform an administrative operation, verify:

1. The Snowflake role currently in use.
2. Whether that role has been granted CUBE_ADMIN.
3. Whether the user is actually operating under the expected Snowflake role.

Do not assume that having broad Snowflake privileges automatically grants a Casabase Cube application role.

Required Account-Level Privileges

Casabase Cube can require Snowflake account-level privileges declared by the Native App.

Two operationally important privileges are:

Privilege	Purpose
READ SESSION	Allows the application to read session context, including CURRENT_USER(). This is required for row-level security evaluation and the Query Builder interface.
EXECUTE MANAGED TASK	Allows scheduled dimension rebuilds and saved-query materialization to run as managed tasks.

For example:

GRANT READ SESSION ON ACCOUNT
TO APPLICATION CASABASE_CUBE;

GRANT EXECUTE MANAGED TASK ON ACCOUNT
TO APPLICATION CASABASE_CUBE;

To review the privileges currently granted to the application:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

If Query Builder or row-level security behavior is failing unexpectedly, verify READ SESSION.

If scheduled rebuilds or saved-query materialization are failing, verify EXECUTE MANAGED TASK.

Access to Customer-Owned Source Data

Casabase Cube cannot read customer-owned Snowflake objects unless the application has been granted the necessary access.

This can include:

• Databases
• Schemas
• Dimension source tables
• Fact tables
• Stages containing import files

For example:

GRANT USAGE ON DATABASE SOURCE_DB
TO APPLICATION CASABASE_CUBE;

GRANT USAGE ON SCHEMA SOURCE_DB.FINANCE
TO APPLICATION CASABASE_CUBE;

GRANT SELECT ON TABLE SOURCE_DB.FINANCE.GL_FACT
TO APPLICATION CASABASE_CUBE;

GRANT READ ON STAGE SOURCE_DB.FINANCE.IMPORT_STAGE
TO APPLICATION CASABASE_CUBE;

Grant only the objects Casabase Cube needs to use.

For source tables, Casabase Cube requires read access. It does not require ownership of customer source data.

Source Object Exists but Casabase Cube Cannot Read It

If a configured source table exists but a build or query reports that it cannot be accessed, check the complete object path:

DATABASE
   │
   ▼
SCHEMA
   │
   ▼
TABLE

Access to the table alone is not sufficient if the application lacks the required access to the containing database or schema.

Verify:

• USAGE on the database
• USAGE on the schema
• SELECT on the source table

Also confirm that the configured database, schema, table, and column names still match the actual source objects.

A renamed or replaced source object can appear to be a permission problem even when the underlying issue is configuration.

Run Health Check to identify source-configuration problems:

CALL CUBE.HEALTH_CHECK('FINANCE');

The INPUT_TABLE_CONFIG check verifies that configured source tables and columns resolve.

See Using Health Check.

Stage Access Problems

If an operation reads files from a customer-owned Snowflake stage, verify that the application has access to the stage.

For example:

GRANT READ ON STAGE SOURCE_DB.FINANCE.IMPORT_STAGE
TO APPLICATION CASABASE_CUBE;

Also verify that:

• The stage exists
• The configured stage name is correct
• The expected file exists on the stage
• The application has the required database and schema access

A successful application-role grant does not automatically grant access to customer-owned stages.

Row-Level Security Is Separate from Application Access

Application roles determine whether a user can use Casabase Cube capabilities.

Casabase Cube row-level security determines which cube members and data a user is permitted to see.

These are separate layers:

Snowflake Role
      │
      ▼
Application Role
      │
      ▼
Can Use Casabase Cube
      │
      ▼
Casabase Cube Security Rules
      │
      ▼
Which Cube Data Is Visible

A user can therefore have CUBE_PUBLIC and still see only a restricted portion of a cube if active Casabase Cube security rules apply to that user.

Security Is Opt-In Per User

Casabase Cube row-level filtering is applied to a user only when both of the following are true:

1. Security is enabled on at least one dimension of the cube.
2. The user has at least one active security rule for that cube.

A user with no active security rules for a cube is unrestricted by Casabase Cube row-level security.

This means:

Security Enabled + User Has Active Rule
                    │
                    ▼
             Filtering Applies


Security Enabled + User Has No Active Rule
                    │
                    ▼
       User Is Not Row-Level Restricted

Enabling security on a dimension does not by itself restrict every user.

See Access Control.

User Sees Less Data Than Expected

If one user sees less cube data than another, review the user’s active security rules.

For example:

SELECT DIM_NAME,
       USER_NAME,
       MEMBER_NAME,
       UPDATED_BY,
       UPDATED_DATE
FROM CASABASE_CUBE.CONFIG.SECURITY
WHERE CUBE_NAME = 'FINANCE'
  AND USER_NAME = 'user@company.com'
  AND ACTIVE = TRUE
ORDER BY DIM_NAME;

Check:

• Which dimensions have security enabled
• Which rules are active for the user
• Which hierarchy branches the rules grant
• Whether the expected parent member was granted
• Whether the user is querying under the expected Snowflake identity

Security rules affect the data visible through supported Casabase Cube query paths.

User Sees More Data Than Expected

This condition deserves immediate review.

Because security is opt-in per user, a user with no active rules is unrestricted by Casabase Cube row-level security.

Check whether the user has any active rules:

SELECT ID,
       DIM_NAME,
       USER_NAME,
       MEMBER_NAME
FROM CASABASE_CUBE.CONFIG.SECURITY
WHERE CUBE_NAME = 'FINANCE'
  AND USER_NAME = 'user@company.com'
  AND ACTIVE = TRUE;

If no rows are returned, the user is not restricted by Casabase Cube row-level security.

For cubes where users are expected to be restricted, administrators should periodically identify users who have queried the cube but have no active security rules.

See Access Control for the recommended access-review workflow.

User Has a Rule but Still Sees Unexpected Results

A security rule grants access to a hierarchy branch according to Casabase Cube’s security semantics.

When troubleshooting unexpected results, verify:

• The rule references the intended dimension
• The member name is correct
• The rule is active
• The hierarchy was rebuilt after relevant metadata changes
• The queried member is inside the permitted branch
• The expected parent or ancestor was granted where appropriate

A partial total can be the expected result of security filtering rather than a data defect.

For example, if a user is permitted to see only part of an organizational hierarchy, an aggregate may reflect only the data visible to that user.

No Active Rule Does Not Explain an Empty Result

Do not troubleshoot an empty query result by assuming that the user lacks a security rule.

Under the Casabase Cube security model:

No active security rule means the user is unrestricted by Casabase Cube row-level security.

If a user with no active rules receives an empty result, investigate other causes such as:

• Incorrect POV members
• No matching fact data
• Dimension state
• Query syntax
• Source data
• A refused query
• Application or Snowflake access problems

See Query Returns No Data.

Query Builder Access Problems

The Query Builder depends on session context.

If users have the appropriate application role but Query Builder does not operate correctly, verify that the application has:

READ SESSION

Review current application grants:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

Also verify that the user’s active Snowflake role has the appropriate Casabase Cube application role.

Scheduled Operation Permission Problems

Scheduled dimension rebuilds and saved-query materialization use Snowflake managed tasks.

If these operations cannot run, verify:

EXECUTE MANAGED TASK

For example:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

If the privilege is absent and the feature is required:

GRANT EXECUTE MANAGED TASK ON ACCOUNT
TO APPLICATION CASABASE_CUBE;

Then investigate the scheduled operation itself if the problem remains.

AI Feature Access

Cortex Agent and MCP-related capabilities can require an additional Snowflake database-role grant:

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER
TO APPLICATION CASABASE_CUBE;

This grant is required only when the applicable AI features are used.

A missing AI-related grant should not affect normal cube configuration or querying.

Recommended Diagnostic Sequence

For an access-related problem:

Identify What Is Failing
        │
        ▼
Verify Current Snowflake Role
        │
        ▼
Verify CUBE_PUBLIC / CUBE_ADMIN
        │
        ▼
Verify Native App Privileges
        │
        ▼
Verify Customer-Object Grants
        │
        ▼
Run HEALTH_CHECK
        │
        ▼
Review User Security Rules
        │
        ▼
Retest

Do not change row-level security rules to solve a Snowflake privilege problem, and do not grant broader Snowflake privileges to solve a Casabase Cube security-rule problem.

If the Problem Remains

Run:

CALL CUBE.HEALTH_CHECK('FINANCE');

Review findings with:

SELECT *
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE STATUS <> 'OK';

If the issue remains unresolved, generate support information:

CALL CUBE.GENERATE_SUPPORT_INFO('FINANCE');

Then collect:

• Exact error message
• User and active Snowflake role
• Application-role grants
• Relevant application grants
• Affected cube and dimension
• Relevant security rules
• Health Check findings
• Approximate time of the failure

Do not include passwords, private keys, authentication tokens, or other credentials.

See Getting Additional Help.

Related Topics

• Roles and Privileges
• Access Control
• Using Health Check
• Query Returns No Data
• Getting Additional Help