Installation for Snowflake Administrators

Casabase Cube is delivered as a Snowflake Native App and is installed into the customer’s Snowflake account.

This guide is intended for Snowflake administrators responsible for installing Casabase Cube and granting application access.

Before You Begin

Before installing Casabase Cube:

Your organization must have access to the Casabase Cube Snowflake listing.
Use a Snowflake role with sufficient privileges to install and configure a Native App.
Decide which Snowflake account roles should receive general Casabase Cube access and which should receive administrative access.
Review your organization’s requirements for approving Native App privileges.

If you do not yet have access to the listing, see How to Get Casabase Cube.

1. Install Casabase Cube

Open the Casabase Cube listing available to your account and follow Snowflake’s current installation workflow.

The listing may be provided through:

Snowflake Marketplace
A private listing from Casabase Software

During installation and configuration, Snowflake presents the privileges and references requested by the Native App.

2. Approve Required Account Privileges

Casabase Cube declares account-level privileges required for supported application functionality.

The core privileges are:

Privilege	Purpose
`READ SESSION`	Allows Casabase Cube to read session context such as `CURRENT_USER()`. Required for row-level security and Query Builder user context.
`EXECUTE MANAGED TASK`	Allows supported scheduled operations to run as Snowflake managed tasks without requiring a customer-owned warehouse for those task executions.

If the privileges are not granted during the installation workflow, they can be granted by an appropriately privileged Snowflake administrator.

For example, replacing CASABASE_CUBE with the installed application name:

GRANT READ SESSION ON ACCOUNT
  TO APPLICATION CASABASE_CUBE;

GRANT EXECUTE MANAGED TASK ON ACCOUNT
  TO APPLICATION CASABASE_CUBE;

Review the application’s current grants with:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

READ SESSION is important even in environments that do not initially configure row-level security because Query Builder also depends on session context.

3. Grant Casabase Cube Application Roles

Casabase Cube defines two application roles:

Application Role	Purpose
`CUBE_PUBLIC`	Query and discovery access. Appropriate for report consumers, analysts, and BI service accounts.
`CUBE_ADMIN`	Modeling and administrative access. Inherits `CUBE_PUBLIC`.

Grant application roles to Snowflake account roles according to your organization’s access model.

For example:

GRANT APPLICATION ROLE CASABASE_CUBE.CUBE_PUBLIC
  TO ROLE CUBE_USER_ROLE;

GRANT APPLICATION ROLE CASABASE_CUBE.CUBE_ADMIN
  TO ROLE CUBE_ADMIN_ROLE;

A user who requires administrative access does not need both application roles because CUBE_ADMIN inherits CUBE_PUBLIC.

Use least privilege. General users should normally receive CUBE_PUBLIC.

See Roles and Privileges for the complete application-role model.

4. Grant Users the Appropriate Snowflake Role

Users receive Casabase Cube application access through the Snowflake account roles to which the application roles were granted.

For example, if:

CUBE_USER_ROLE
      │
      └── CASABASE_CUBE.CUBE_PUBLIC

is the organization’s general-user role path, grant CUBE_USER_ROLE to the appropriate users according to your normal Snowflake RBAC process.

Casabase Cube does not require a separate application username or password.

5. Grant Access to Customer-Owned Source Objects When Required

Installing the Native App does not automatically give Casabase Cube access to customer-owned Snowflake objects.

If a cube will read a customer-owned table or use a customer-owned stage, explicitly grant only the required access.

A typical table-source pattern can require:

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;

A customer-owned migration stage can require:

GRANT USAGE ON DATABASE SOURCE_DB
  TO APPLICATION CASABASE_CUBE;

GRANT USAGE ON SCHEMA SOURCE_DB.FINANCE
  TO APPLICATION CASABASE_CUBE;

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

Grant SELECT or READ as appropriate rather than ownership. Casabase Cube reads customer-owned source objects; it does not require ownership of them.

Only grant access to objects the configured cubes actually require.

6. Optional AI Capabilities

Snowflake Intelligence and Cortex Agent capabilities require additional Snowflake configuration beyond the core Casabase Cube installation.

Do not grant broader Cortex or agent privileges solely for standard Casabase Cube querying and administration.

If you plan to use the Intelligence integration, follow Setting Up the Agent for the current requirements rather than relying on older Native App installation guidance.

7. Verify Installation

After installation, verify:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

Then confirm that:

Required account privileges have been approved.
Intended Snowflake roles hold CUBE_PUBLIC or CUBE_ADMIN as appropriate.
Users can open Casabase Cube from Snowflake.
A CUBE_PUBLIC user can access supported query and discovery functionality.
A CUBE_ADMIN user can access configuration and administrative functionality.
Any required customer-owned tables or stages have been explicitly granted to the application.

8. Continue with Initial Setup

After access is working:

Use First Login & Orientation to review the application.
Use the 5-Minute Quick Start for an Oracle Essbase or Cloud EPM migration.
Use Creating a Cube from Snowflake Data to build a new cube from Snowflake data.

Security Notes

Application access and Casabase Cube row-level security are separate.

Granting CUBE_PUBLIC allows a user to access supported Casabase Cube query functionality. Row-level security, when configured for a user, can further restrict which portions of a cube that user may query.

Casabase Cube row-level security is opt-in per user. A user with application access but no active security rules for a cube is unrestricted by Casabase Cube row-level security.

See Access Control for the complete security model.