Skip to content
Casabase CubeCasabase Cube Documentation

Installation & Access

How do I install Casabase Cube?

Section titled “How do I install Casabase Cube?”

Casabase Cube is delivered as a Snowflake Native App.

Depending on how Casabase Cube is made available to your organization, it can be acquired through the Snowflake Marketplace or through a supported private listing.

Installation creates the Casabase Cube application within your Snowflake account.

For the complete installation procedure, see Installation for Snowflake Administrators.

What Snowflake role do I need to install Casabase Cube?

Section titled “What Snowflake role do I need to install Casabase Cube?”

Installation must be performed by a Snowflake role with the privileges required to install and configure a Native App in your account.

The exact administrative role does not have to be used for normal Casabase Cube access after installation.

Organizations should follow their normal Snowflake administrative and least-privilege practices when assigning installation privileges.

See Installation for Snowflake Administrators for the current installation requirements.

What privileges does Casabase Cube require?

Section titled “What privileges does Casabase Cube require?”

Casabase Cube uses two account-level Snowflake privileges for supported application functionality:

READ SESSION
EXECUTE MANAGED TASK

READ SESSION

Section titled “READ SESSION”

READ SESSION allows Casabase Cube to evaluate Snowflake session context required by application functionality.

This includes identifying the current Snowflake user for capabilities such as:

  • Row-level security
  • User-aware query processing
  • Query Builder user context

Conceptually:

Snowflake Session
       │
       ▼
CURRENT_USER()
       │
       ▼
Casabase Cube
       │
       ▼
User-Specific Behavior

EXECUTE MANAGED TASK

Section titled “EXECUTE MANAGED TASK”

EXECUTE MANAGED TASK allows supported Casabase Cube scheduled operations to execute using Snowflake serverless managed tasks.

This can be used by functionality such as scheduled queries and supported automated operations.

See Roles and Privileges for the definitive privilege requirements.

Does installing Casabase Cube give it access to all of my Snowflake data?

Section titled “Does installing Casabase Cube give it access to all of my Snowflake data?”

No.

Installing Casabase Cube does not automatically give the application access to arbitrary databases, schemas, tables, views, or stages in the customer’s Snowflake account.

Access to customer-owned objects must be explicitly granted when those objects are needed by Casabase Cube.

Conceptually:

Customer Snowflake Account
│
├── Database A
├── Database B
├── Stages
├── Tables
└── Casabase Cube
        │
        └── No Automatic Access

The customer determines which source objects are made available to the Native App.

How do I give Casabase Cube access to customer-owned data?

Section titled “How do I give Casabase Cube access to customer-owned data?”

Customer-owned Snowflake objects are made available to Casabase Cube through the supported Snowflake Native App access model.

Depending on the object and workflow, access can require privileges such as:

USAGE
SELECT
READ

For example, Casabase Cube may require access to:

  • Dimension definition tables
  • Source fact data
  • Stages containing migration artifacts
  • Other explicitly configured source objects

Only the objects required for the intended workflow should be made available.

See Roles and Privileges for the current grant procedures and examples.

Can I limit Casabase Cube to specific source objects?

Section titled “Can I limit Casabase Cube to specific source objects?”

Yes.

Casabase Cube does not require unrestricted access to the customer’s Snowflake environment.

Access can be limited to the specific objects required by the application.

For example:

FINANCE_DB
│
└── PLANNING
    ├── DIM_ACCOUNT     ← Granted
    ├── DIM_ENTITY      ← Granted
    ├── FACT_PLAN       ← Granted
    └── HR_SALARIES     ← Not Granted

Casabase Cube can access the objects made available to it without receiving access to unrelated customer data.

This supports Snowflake least-privilege practices.

Can I revoke access to customer-owned data?

Section titled “Can I revoke access to customer-owned data?”

Yes.

Access to customer-owned Snowflake objects remains under customer control.

If access that Casabase Cube depends on is revoked, application functionality requiring that object can no longer use it.

For example, removing access to a dimension definition table can prevent subsequent validation or rebuild operations that depend on that table.

Revoking access does not necessarily remove data that has already been loaded into the application-managed cube.

This distinction is important:

Customer Source Object
        │
        ├── Access Can Be Revoked
        │
        ▼
Casabase Cube Load
        │
        ▼
Application-Managed Cube Data

Source-object access and application-managed cube data are separate.

See Data Storage & Boundaries.

What application roles does Casabase Cube provide?

Section titled “What application roles does Casabase Cube provide?”

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.

CUBE_PUBLIC is intended for users and applications that need to query Casabase Cube or use supported discovery functionality.

CUBE_ADMIN adds capabilities for configuring and administering cubes.

How do I give users access to Casabase Cube?

Section titled “How do I give users access to Casabase Cube?”

Casabase Cube application roles are granted to Snowflake account roles.

For example:

GRANT APPLICATION ROLE
    CASABASE_CUBE.CUBE_PUBLIC
TO ROLE ANALYST;

An administrative Snowflake role can be granted:

GRANT APPLICATION ROLE
    CASABASE_CUBE.CUBE_ADMIN
TO ROLE CUBE_ADMINISTRATOR;

Replace:

CASABASE_CUBE

with the name of your installed Casabase Cube application.

Users then receive Casabase Cube capabilities through their Snowflake role assignments.

Conceptually:

Snowflake User
      │
      ▼
Snowflake Account Role
      │
      ▼
Casabase Cube
Application Role
      │
      ▼
Application Capabilities

See Roles and Privileges.

Should every user receive CUBE_ADMIN?

Section titled “Should every user receive CUBE_ADMIN?”

No.

CUBE_ADMIN provides modeling and administrative capabilities and should be limited to users who require those functions.

Most query consumers should normally receive:

CUBE_PUBLIC

through an appropriate Snowflake account role.

Conceptually:

Analysts / BI Users
        │
        ▼
    CUBE_PUBLIC




Cube Administrators
        │
        ▼
     CUBE_ADMIN

This supports the principle of least privilege.

Does CUBE_PUBLIC determine which cube data a user can see?

Section titled “Does CUBE_PUBLIC determine which cube data a user can see?”

Not by itself.

Application roles and row-level security serve different purposes.

Application Role
       │
       ▼
What can the user do?




Row-Level Security
       │
       ▼
Which cube data can
the user see?

CUBE_PUBLIC provides application query access.

Casabase Cube row-level security can then restrict the multidimensional data available to an individual user.

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.

Does Casabase Cube create separate Snowflake users?

Section titled “Does Casabase Cube create separate Snowflake users?”

No.

Casabase Cube uses Snowflake identity and session context rather than maintaining a separate application user directory.

Users access Casabase Cube through their Snowflake identities and roles.

This allows organizations to continue using their existing Snowflake identity, authentication, and role-management processes.

Does Casabase Cube require separate passwords or authentication?

Section titled “Does Casabase Cube require separate passwords or authentication?”

No separate Casabase Cube authentication system is required.

Authentication is handled through Snowflake.

Casabase Cube uses the authenticated Snowflake session and applicable Snowflake roles and application roles to determine application access and user context.

How does Casabase Cube identify the current user?

Section titled “How does Casabase Cube identify the current user?”

Casabase Cube can use Snowflake session context, including:

CURRENT_USER()

to identify the authenticated Snowflake user.

This user context is important for capabilities such as row-level security.

The required Snowflake READ SESSION privilege allows the Native App to use the necessary session information.

Does Casabase Cube support service accounts or programmatic users?

Section titled “Does Casabase Cube support service accounts or programmatic users?”

Casabase Cube access follows Snowflake’s identity and role model.

A Snowflake identity used by an application or programmatic client can access Casabase Cube when it has the appropriate Snowflake role and Casabase Cube application-role grants.

The appropriate authentication method and identity lifecycle remain governed by the customer’s Snowflake security practices.

Does Casabase Cube require access to the public internet?

Section titled “Does Casabase Cube require access to the public internet?”

Core Casabase Cube processing does not require external network access.

The application runs inside the customer’s Snowflake environment and reports:

data_egress           NONE
external_connections  NONE
pii_collection        NONE
telemetry             DISABLED

Casabase Cube does not require customer cube data to be sent to Casabase-operated infrastructure for processing.

See Compliance and Privacy.

Does Casabase Cube require a separate database server?

Section titled “Does Casabase Cube require a separate database server?”

No.

Casabase Cube is a Snowflake Native App.

The application uses Snowflake for its underlying storage and compute rather than requiring a separately deployed OLAP database or application server.

Does Casabase Cube require a dedicated Snowflake warehouse?

Section titled “Does Casabase Cube require a dedicated Snowflake warehouse?”

Not necessarily.

Warehouse requirements depend on the operation and workload.

Casabase Cube uses Snowflake compute according to the architecture of the particular feature. Some supported scheduled functionality can also use Snowflake serverless managed tasks.

Review System Requirements and the relevant feature documentation when planning compute.

What additional access is required for AI functionality?

Section titled “What additional access is required for AI functionality?”

Snowflake Intelligence and Cortex Agent functionality requires additional Snowflake capabilities beyond the core Casabase Cube application roles.

The exact requirements depend on the enabled Cortex Agent capabilities and tools. They can include the applicable Snowflake Cortex database role, warehouse access, the appropriate Casabase Cube application role, and privileges or caller grants for consumer-owned objects used by agent tools.

AI functionality is optional and is not required for normal Casabase Cube modeling or querying.

See Roles and Privileges and Setting Up the Agent.

How are application upgrades handled?

Section titled “How are application upgrades handled?”

Casabase Cube follows the Snowflake Native App application lifecycle.

Application upgrades can update the installed Casabase Cube version while preserving customer-specific application state according to the supported upgrade process.

State that can persist across upgrades includes:

  • Cubes
  • Dimension definitions
  • Formulas
  • Data
  • Security rules
  • Data classifications
  • Saved Queries
  • Schedules
  • Audit history

Administrators should validate the application after an upgrade rather than assuming that every cube migration succeeded solely because the application upgrade completed.

See Application Upgrades.

What should I check after installation?

Section titled “What should I check after installation?”

After installing Casabase Cube, a typical initial validation sequence is:

Install Native App
       │
       ▼
Grant Required
Application Privileges
       │
       ▼
Grant Required
Source Access
       │
       ▼
Assign Application Roles
       │
       ▼
Open Casabase Cube
       │
       ▼
Create or Import a Cube
       │
       ▼
Run HEALTH_CHECK
       │
       ▼
Run Verification Query

The exact steps depend on whether you are creating a cube from Snowflake data or migrating an existing Oracle Essbase or Cloud EPM application.

See:

Where can I find the definitive access and privilege requirements?

Section titled “Where can I find the definitive access and privilege requirements?”

Use Roles and Privileges as the definitive reference for:

  • Casabase Cube application roles
  • Snowflake account-level privileges
  • Customer source-object access
  • Stage access
  • Cortex access
  • Least-privilege configuration

The FAQ provides the conceptual overview, while the Administration documentation contains the detailed procedures.