Integration Points

Casabase Cube is designed to integrate through Snowflake-native interfaces.

There is no Casabase-specific driver, XMLA endpoint, gateway, or separate middleware service to deploy. If a tool can connect to Snowflake, it can consume Casabase Cube through one of the supported integration surfaces.

The appropriate integration pattern depends on whether the consumer needs:

• relational leaf-level data
• full multidimensional calculation semantics
• repeatedly consumed materialized results
• natural-language or AI access

Integration Architecture

At a high level:

Casabase Cube
      │
      ├── Secure Views
      │
      ├── Materialized Reporting Tables
      │
      ├── Query Procedures
      │
      └── AI Interfaces
      │
      ▼
Snowflake
      │
      ▼
Consuming Tool

The supported consumption surfaces include:

QUERY_CUBE
QUERY_CUBE_PIVOT_JSON

<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS

SHARED_DATA reporting tables

Cortex Agent
MCP server

These are the interfaces applications should build against rather than application-internal objects.

Four Integration Patterns

Casabase Cube supports four primary integration patterns:

Pattern	Surface	Best Fit
1. Secure views	<CUBE>_FACT_SECURE, <CUBE>_DIMENSIONS	Tool needs tables or views and will model in the consuming layer
2. Materialized reporting tables	Scheduled Saved Queries → SHARED_DATA	Tool cannot call procedures or the same result is read repeatedly
3. Live procedure call	CALL + RESULT_SCAN	Tool supports multi-statement SQL and needs full cube semantics
4. AI / conversational	Cortex Agent, MCP server	Natural-language and AI-based access

These four patterns form the primary integration architecture.

Choosing the Right Pattern

A useful decision flow is:

Need Cube-Calculated Values?
        │
        ├── No
        │    │
        │    ▼
        │ Secure Views
        │
        └── Yes
             │
             ▼
Can the Tool Call Procedures?
             │
       ┌─────┴─────┐
       │           │
      Yes          No
       │           │
       ▼           ▼
CALL +          Materialized
RESULT_SCAN     Reporting Table

For natural-language access:

Natural-Language / AI Consumer
              │
              ▼
      Cortex Agent or MCP

The key distinction is whether the consuming tool needs the cube calculation engine or only the underlying relational data.

Pattern 1: Secure Views

Each cube exposes two primary secure views:

<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS

Together they provide a conventional relational model suitable for BI tools and SQL consumers.

Secure Fact View

The fact view contains:

One column per dimension
+
AMT

For example:

ACCOUNT
ENTITY
PRODUCT
PERIOD
SCENARIO
AMT

It exposes the stored fact-level data permitted to the current user.

Secure Dimension View

The dimension view contains hierarchy metadata for all cube dimensions, distinguished by:

DIM_NAME

Metadata includes concepts such as:

• Member
• Parent
• Alias
• Generation
• Level
• Leaf status
• Sort order
• UDA
• Time-balance metadata

A BI model can separate this into individual dimension tables if desired.

Example Relational Query

For example:

SELECT
    d.PARENT AS product_group,
    f.PRODUCTS,
    SUM(f.AMT) AS units
FROM CASABASE_CUBE.SHARED_DATA.ASOSAMP_FACT_SECURE f
JOIN CASABASE_CUBE.SHARED_DATA.ASOSAMP_DIMENSIONS d
  ON d.DIM_NAME = 'PRODUCTS'
 AND d.CHILD = f.PRODUCTS
WHERE f.MEASURES = 'Units'
  AND f.YEARS = 'Curr Year'
  AND d.ISLEAF
GROUP BY
    d.PARENT,
    f.PRODUCTS
ORDER BY
    units DESC;

This is ordinary Snowflake SQL over the supported secure views.

BI Star-Schema Pattern

For a BI semantic model, individual dimension views can be created from <CUBE>_DIMENSIONS.

For example:

CREATE OR REPLACE VIEW MY_DB.BI.DIM_PRODUCTS AS
SELECT
    CHILD AS PRODUCT,
    PARENT,
    ALIAS,
    GENERATION,
    LEVEL,
    ISLEAF,
    SORTORDER
FROM CASABASE_CUBE.SHARED_DATA.ASOSAMP_DIMENSIONS
WHERE DIM_NAME = 'PRODUCTS';

The resulting BI model can look like:

DIM_ACCOUNT ─────┐
DIM_ENTITY ──────┤
DIM_PRODUCT ─────┼── FACT_SECURE
DIM_PERIOD ──────┤
DIM_SCENARIO ────┘

This gives conventional star-schema behavior to tools that prefer relational semantic models.

Secure View Tradeoff

Secure views provide:

Stored facts
+
Hierarchy metadata
+
Row-level security

They do not reproduce the Casabase Cube calculation engine.

Specifically, direct use of the views does not provide:

• Member formulas
• Calculated members
• Cube hierarchy aggregation semantics
• Time-balance processing

The consuming application performs its own calculations.

The authoritative guide summarizes the distinction as:

Calculation Engine           Secure Views
--------------------------   --------------------------
Hierarchy aggregation        Stored leaf data
Member formulas              No calculated members
Time intelligence            No time-balance processing
POV selection                SQL predicates
Procedure call               Plain SELECT
Security enforced            Security enforced

If a value must match the number Casabase Cube calculates, retrieve it through the calculation engine rather than independently re-aggregating the secure fact view.

Pattern 2: Materialized Reporting Tables

Materialized reporting tables provide cube-calculated results through ordinary Snowflake tables.

A Saved Query is scheduled, calculated by Casabase Cube, and written to:

SHARED_DATA

Conceptually:

Saved Query
      │
      ▼
Casabase Cube Engine
      │
      ▼
Formulas + Aggregation + Time Intelligence
      │
      ▼
SHARED_DATA Table
      │
      ▼
BI / Reporting Tool

Example Scheduled Result

For example:

CALL CUBE.SCHEDULE_SAVED_QUERY(
    'FINANCE',
    'Monthly P&L',
    'RPT_MONTHLY_PL',
    'USING CRON 0 6 * * * America/New_York',
    'SMALL',
    TRUE
);

Consumers then use:

SELECT *
FROM CASABASE_CUBE.SHARED_DATA.RPT_MONTHLY_PL;

Each run fully replaces the output table. The result is a snapshot rather than an accumulating history.

Why Materialize

This pattern works well when:

• The consuming tool cannot call stored procedures
• The same result is read repeatedly
• Dashboard latency should be independent of live cube calculation
• Calculated members are required
• Time-balance behavior is required
• A conventional Snowflake table is preferred

Instead of recalculating the cube every time a dashboard opens:

Dashboard Open
      │
      ▼
Run Full Cube Query

the pattern becomes:

Scheduled Refresh
      │
      ▼
Calculate Once
      │
      ▼
Reporting Table
      │
      ├── Dashboard Read
      ├── Dashboard Read
      ├── Dashboard Read
      └── Dashboard Read

This is particularly appropriate when reads occur much more frequently than underlying data changes.

Materialization Security Boundary

Materialization changes the security boundary.

The Saved Query executes under a particular Snowflake identity:

Execution Identity
      │
      ▼
Casabase Cube Security
      │
      ▼
Calculated Result
      │
      ▼
Snowflake Table

Security is resolved when the table is written.

After that, consumers are reading an ordinary Snowflake table. Snowflake table grants determine who can read it.

Casabase Cube row-level security does not dynamically reevaluate for every table consumer.

Therefore, do not use one materialized result for audiences that require different cube security scopes.

Either:

Query the Cube Per User

or:

Create Separate Materializations Per Audience

Pattern 3: Live Procedure Call

When a tool can execute multiple SQL statements in the same Snowflake session, it can call the calculation engine directly and then consume the result relationally.

The pattern is:

CALL CUBE.QUERY_CUBE(
    'ASOSAMP',
    '{
        "MEASURES": [{"children": "Ratios"}],
        "TIME": ["Qtr1"],
        "YEARS": ["Curr Year"]
    }',
    NULL,
    NULL
);

SELECT *
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

This provides full Casabase Cube calculation semantics without creating a persistent reporting table.

What Pattern 3 Provides

A live procedure call includes:

• POV resolution
• Hierarchy-aware aggregation
• Member formulas
• Time intelligence
• Solve order
• Current-user security

Conceptually:

Tool
 │
 ▼
CALL QUERY_CUBE
 │
 ▼
Casabase Cube Engine
 │
 ▼
RESULT_SCAN
 │
 ▼
Relational Result

The consuming tool receives a relational result while calculation remains governed by the cube model.

Session Requirement

RESULT_SCAN(LAST_QUERY_ID()) depends on Snowflake session state.

The CALL and subsequent RESULT_SCAN therefore need to run within the same session.

This makes the pattern suitable for tools and applications that can control their SQL session.

Most BI semantic models expect a single SELECT against a named object and therefore cannot use this pattern directly. For those tools, secure views or materialized tables are generally a better fit.

On-Demand Materialization

A variation of pattern 3 is to have the engine write an on-demand extract:

CALL CUBE.QUERY_CUBE(
    'FINANCE',
    '<pov>',
    'EXTRACT_TARGET',
    NULL
);

SELECT *
FROM CASABASE_CUBE.SHARED_DATA.EXTRACT_TARGET;

This provides cube-calculated results without depending on RESULT_SCAN session state.

Use this pattern when an extract is needed on demand rather than through a recurring Saved Query schedule.

Pattern 4: AI and Conversational Access

Casabase Cube can make its governed multidimensional model available through Snowflake Intelligence and Cortex Agents.

The conversational layer interprets a user’s request and orchestrates configured tools, while Casabase Cube remains responsible for the multidimensional result.

Conceptually:

Natural-Language Question
          │
          ▼
Snowflake Intelligence
          │
          ▼
Cortex Agent
          │
          ▼
Casabase Cube Tools
          │
          ▼
Casabase Cube Query Engine
          │
          ▼
Governed Result

This preserves the same architectural separation used elsewhere in Casabase Cube:

• Snowflake provides the agent platform and conversational experience.
• Casabase Cube exposes cube-aware discovery and query capabilities.
• The Casabase Cube query engine applies hierarchy, aggregation, formula, time, and security semantics.
• Agent access does not create an alternate path around Casabase Cube security.

Agent Security Boundary

The current Casabase Cube Intelligence integration uses an app-created Cortex Agent within the Snowflake Native App model.

Access to the agent, its tools, and any consumer-owned Snowflake objects remains governed by Snowflake privileges, Native App controls, caller grants where required, and Casabase Cube application roles.

An app-created agent does not automatically gain unrestricted access to customer-owned Snowflake objects.

Intelligence Setup

Agent configuration and Snowflake requirements can evolve independently of the core Casabase Cube query architecture.

For current setup, access, and governance requirements, use the Intelligence documentation rather than older standalone-agent DDL patterns:

• Intelligence Overview
• Setting Up the Agent
• Governance and Security

MCP and Other AI Integration Patterns

Snowflake AI capabilities can also include MCP-based integration patterns. Only capabilities explicitly configured and authorized for the environment should be treated as available.

The same general rule applies: AI tooling should consume supported Casabase Cube interfaces rather than depend on undocumented internal application objects.

Built-In Streamlit Interface

Casabase Cube also includes its own Streamlit interface.

The built-in application can be used for:

• Modeling
• Querying
• Administration
• Model validation

It requires no separate integration layer and is particularly useful when validating a cube before exposing it to external consuming tools.

Power BI

Power BI connects through the standard Snowflake connector.

Two primary approaches are available:

Exploratory / Interactive Model
        │
        ▼
Secure Views

and:

Fixed Dashboard
        │
        ▼
Scheduled Reporting Table

Power BI Semantic Model

A typical model uses:

<CUBE>_FACT_SECURE

as the fact table and separate relational dimension views derived from:

<CUBE>_DIMENSIONS

Conceptually:

Dimension Views
      │
      ▼
Power BI Relationships
      │
      ▼
FACT_SECURE

Power BI then provides its own semantic-model aggregation and measures.

Power BI Import

For Import mode, a scheduled materialized table is a strong fit.

The dashboard reads a precomputed cube result:

Casabase Cube Refresh
      │
      ▼
Reporting Table
      │
      ▼
Power BI Import

This decouples dashboard refresh performance from live cube calculation.

Power BI DirectQuery

DirectQuery can point to the secure views.

Per-user cube security is preserved only when the report connects using the viewer’s Snowflake identity.

If every viewer connects through a shared Snowflake service identity:

All Power BI Users
        │
        ▼
Shared Service Account
        │
        ▼
One Casabase Cube Security Scope

then all viewers receive the security scope of that shared identity rather than their individual Casabase Cube scopes.

Power BI and Calculated Members

Power BI cannot call a procedure as a modeled table.

Therefore, Casabase Cube calculated members must either:

Come from a Materialized Cube Result

or:

Be Reimplemented in DAX Over Leaf Data

if the secure-view model is used.

If exact Casabase Cube calculation semantics are required, materialization is the safer option.

Tableau

Tableau also connects through the standard Snowflake connector.

The recommended approaches are:

Live Secure Views

or:

Extract from Materialized Reporting Table

Tableau Modeling

The secure fact view can serve as the primary data source, while dimension metadata can be joined for hierarchy information.

Hierarchy properties such as:

GENERATION
LEVEL

can be used to build Tableau hierarchy behavior.

Tableau Security

With a live connection and per-user Snowflake credentials:

Tableau User
      │
      ▼
Snowflake Identity
      │
      ▼
Casabase Cube Security

the user’s cube security scope is enforced.

A Tableau extract is different.

The extract reflects the security scope of the identity that created it. After extraction, the user is consuming the extract rather than dynamically querying Casabase Cube.

Architecturally, this behaves like materialization.

Excel

For Excel-style grid consumption, a practical pattern is:

QUERY_CUBE_PIVOT_JSON

The interface returns a pivoted result with column headers, matching the way spreadsheet users often work with multidimensional data.

Conceptually:

POV
 │
 ▼
QUERY_CUBE_PIVOT_JSON
 │
 ▼
Rows + Pivoted Columns
 │
 ▼
Excel Grid

An alternative is Snowflake ODBC against a scheduled reporting table for a refreshable relational dataset.

Alteryx

Alteryx can connect through:

Snowflake ODBC
Snowflake bulk connector

For leaf-level relational data:

Input Data
   │
   ▼
Secure Views

For full calculation-engine behavior:

Pre-SQL:
CALL CUBE.QUERY_CUBE(...)

Then:
SELECT *
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

For scheduled workflows, writing the result to a table can be more robust than relying on session state.

Alteryx Write-Back Pattern

Alteryx writes output to customer-controlled Snowflake tables rather than directly modifying Casabase Cube source data.

Those tables can then become sources for:

• Dimensions
• Facts
• Driver data
• Allocation inputs

Conceptually:

Alteryx
   │
   ▼
Customer Snowflake Table
   │
   ▼
Casabase Cube Source
   │
   ▼
Rebuild / Query

This is a common pattern for driver tables and allocation inputs.

Python and Custom Applications

Python applications can connect using standard Snowflake interfaces such as:

Snowflake Python Connector
Snowpark

For full cube semantics, use:

CALL + RESULT_SCAN

For large relational reads, use:

Secure Views

This allows an application to choose dynamically between:

Need calculated cube result
        │
        ▼
QUERY_CUBE

and:

Need stored leaf data
        │
        ▼
FACT_SECURE

dbt

dbt models are fundamentally SELECT-based.

They can therefore model directly on:

<CUBE>_FACT_SECURE
<CUBE>_DIMENSIONS

like ordinary Snowflake sources.

When a dbt model needs a cube-calculated result, use a materialized reporting table produced by Casabase Cube because calculated results require the engine rather than a simple SELECT over the fact view.

Conceptually:

dbt Needs Leaf Data
      │
      ▼
Secure Views

versus:

dbt Needs Cube Calculation
      │
      ▼
Scheduled Casabase Result Table

External Orchestration

External applications can also orchestrate Casabase Cube operations using supported procedures.

Operations that can participate in external orchestration include:

REBUILD_DIMENSIONS
RUN_SCHEDULED_QUERY

as procedures that can be triggered from customer-controlled schedulers when preferred over Casabase Cube’s built-in scheduling.

This allows Casabase Cube to participate in broader Snowflake or enterprise orchestration workflows.

Per-User Security in External Tools

A critical integration rule is:

Per-user Casabase Cube security requires per-user Snowflake identity at the point the cube is queried.

For example:

User A
  │
  ▼
Snowflake Identity A
  │
  ▼
Casabase Security A

User B
  │
  ▼
Snowflake Identity B
  │
  ▼
Casabase Security B

If both users instead connect through:

SERVICE_ACCOUNT

Casabase Cube sees:

CURRENT_USER() = SERVICE_ACCOUNT

and therefore applies the service account’s security scope to both.

This applies to live secure-view and live procedure-call integrations.

Integration Security by Pattern

Pattern	Security Evaluation
Secure views	Current connecting Snowflake user
Materialized reporting table	Identity that writes the table; later reads use Snowflake table grants
Live procedure call	Current connecting Snowflake user
AI / conversational	Connecting/requesting identity through the supported Snowflake integration

Materialization differs from the other patterns because its security scope is fixed at write time.

Integration and Refusal Behavior

Applications that call the calculation engine should also account for Casabase Cube’s refusal model.

If a requested calculation cannot be produced correctly, the engine can return an explicit error rather than an approximation.

Integrations using:

QUERY_CUBE
QUERY_CUBE_PIVOT_JSON
CALL + RESULT_SCAN

should therefore surface meaningful query errors to the consumer rather than silently converting them into blanks or generic failures.

This is especially relevant for custom applications and automated integrations.

Stable Integration Boundary

Applications should integrate only through supported interfaces.

The architecture contract is:

Documented Procedure?
        │
        ├── Yes ──► Supported
        │
        └── No
              │
              ▼
Secure Cube View?
        │
        ├── Yes ──► Supported
        │
        └── No
              │
              ▼
Casabase-Created Reporting Table?
        │
        ├── Yes ──► Supported Consumption Object
        │
        └── No ──► Treat as Internal

Internal application objects can be changed or migrated between Native App versions. The consumption surface is the supported integration boundary.

No Proprietary Integration Layer

Casabase Cube does not require:

Casabase Driver
XMLA
MDX Endpoint
External Gateway
Vendor Middleware
Separate Application Server

Instead:

Existing Snowflake Connectivity
          │
          ▼
Casabase Cube

is the integration model.

This lets organizations use their existing Snowflake connectivity, identity, networking, BI tooling, and data-platform practices.

Integration Pattern Summary

Use secure views when:

The consuming tool wants tables
+
You want native BI modeling
+
Leaf data is sufficient

Use materialized reporting tables when:

You need cube-calculated values
+
The tool cannot call procedures

or:

The same result is consumed repeatedly

Use live procedure calls when:

You need full cube semantics
+
The tool can execute multi-statement Snowflake SQL

Use AI interfaces when:

You want natural-language access
+
Snowflake Cortex or MCP is the consuming model

Key Principles

• Snowflake is the integration boundary.
• No Casabase-specific driver or gateway is required.
• Integrations should use documented procedures, secure views, reporting tables, or supported AI interfaces.
• Secure views expose leaf facts and hierarchy metadata, not full cube calculation semantics.
• Materialized tables preserve cube-calculated output but resolve security at write time.
• CALL + RESULT_SCAN provides live full-engine semantics to tools that support multi-statement SQL.
• Power BI and Tableau can model directly over secure Snowflake views.
• Per-user security requires the consumer to preserve the viewer’s Snowflake identity.
• Shared service identities result in a shared cube security scope.
• Excel is well matched to QUERY_CUBE_PIVOT_JSON.
• Alteryx can use secure views, live procedure calls, or materialized output.
• Python and custom applications can choose between relational and engine interfaces.
• dbt should consume secure views or pre-materialized cube-calculated results.
• Cortex Agent and MCP provide AI-oriented consumption patterns.
• Customer-created objects outside the Native App remain customer-managed across upgrades.
• Internal Casabase Cube objects are not a supported integration target.

Related Topics

• High-Level Architecture
• Data Storage & Boundaries
• Query Architecture
• Security Model
• Querying with SQL
• Saved Queries
• Application Upgrades