Skip to content
Casabase CubeCasabase Cube Documentation

Logging & Auditability

Casabase Cube maintains an application-level audit log for significant administrative and data-access activity.

The audit log records application context such as:

  • Who performed an operation
  • What operation occurred
  • When it occurred
  • Which cube or object was involved
  • Whether the operation succeeded or failed
  • Execution timing
  • Rows processed where applicable
  • Event-specific details

The log is maintained inside the installed Casabase Cube Native Application in the customer’s Snowflake account. Audit information is not sent to a provider-hosted logging service.

Audit Architecture

Section titled “Audit Architecture”

Conceptually:

User or Scheduled Operation
          │
          ▼
Casabase Cube
          │
          ├── Query
          ├── Modeling Operation
          ├── Security Change
          ├── Data Operation
          ├── Scheduled Operation
          └── Administrative Change
          │
          ▼
Application Audit Event
          │
          ▼
Casabase Cube Audit Log
          │
          ▼
Customer Snowflake Account

This keeps application activity within the same Snowflake environment where the application and customer data operate.

The audit log is part of Casabase Cube’s application-managed internal storage. Administrative and data-access activity is recorded within the customer’s Snowflake account.

Application-Level Context

Section titled “Application-Level Context”

Snowflake provides platform-level information such as:

  • Authentication
  • Sessions
  • Query history
  • Role activity
  • Object access
  • Account activity

Casabase Cube adds application-specific context.

Conceptually:

Snowflake
│
├── User Authentication
├── Session Context
├── Query History
└── Platform Operations
        │
        ▼
Casabase Cube
│
├── Cube Operations
├── Dimension Operations
├── Formula Operations
├── Security Operations
├── Saved Query Operations
├── Data Operations
└── Application Administration

The two layers are complementary.

Snowflake can establish that a Snowflake operation occurred, while the Casabase Cube audit log can describe what that operation represented in terms of the multidimensional application.

What Is Recorded

Section titled “What Is Recorded”

Casabase Cube records significant operations across major functional areas.

These include activity related to:

Application Lifecycle
Dimensions and Hierarchies
Data Loading
Formulas
Security
Queries
Saved Queries and Scheduling
Cube Configuration
Other Administrative Operations

The Administration reference identifies event categories covering application events, dimension activity, data operations, formulas, queries, scheduled operations, and cube lifecycle/configuration changes.

Data Queries Are Audited

Section titled “Data Queries Are Audited”

Data-access activity is represented in the audit log.

For example:

DATA_QUERY

events can be used to determine which users are querying particular cubes.

This is architecturally important because Casabase Cube’s row-level security model is opt-in per user.

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

Audit data therefore provides the information necessary to identify users who are actively querying a secured cube without an active row-level security rule.

Auditability and Opt-In Security

Section titled “Auditability and Opt-In Security”

The security architecture creates a specific audit requirement.

Because:

No Security Rule
        │
        ▼
Unrestricted Cube Scope

administrators must be able to distinguish:

Intentionally Unrestricted User

from:

User Who Was Never Provisioned with a Required Rule

Casabase Cube audit events make this review possible.

Conceptually:

Audit Log
   │
   ▼
Users Who Queried Cube
   │
   ▼
Compare with Active Security Rules
   │
   ▼
Intended?
   │
   ├── Yes ──► No Action
   │
   └── No  ──► Security Review

Because row-level security is opt-in per user, administrators should include users without active security rules in periodic access reviews.

See Security Model for the complete security architecture.

Audit Event Structure

Section titled “Audit Event Structure”

Audit records contain a consistent set of fields that allow activity to be analyzed across different event types.

The supported audit export includes:

ID
EVENT_TYPE
USER_NAME
ROLE_NAME
ACTION
OBJECT_TYPE
OBJECT_NAME
CUBE_NAME
DETAILS
EXECUTION_TIME_MS
ROW_COUNT
STATUS
ERROR_MESSAGE
SESSION_ID
CREATED_AT

This provides several dimensions of auditability:

Identity
    USER_NAME
    ROLE_NAME
    SESSION_ID


Operation
    EVENT_TYPE
    ACTION


Object
    OBJECT_TYPE
    OBJECT_NAME
    CUBE_NAME


Outcome
    STATUS
    ERROR_MESSAGE


Performance
    EXECUTION_TIME_MS
    ROW_COUNT


Context
    DETAILS
    CREATED_AT

Event-Specific Details

Section titled “Event-Specific Details”

The:

DETAILS

field contains JSON with context specific to the type of operation.

For example, it can contain information associated with:

  • An application upgrade
  • A scheduled query
  • Configuration changes
  • Other application operations

This provides flexibility to retain meaningful application context without requiring every event type to have a completely different table structure.

Identity Attribution

Section titled “Identity Attribution”

Audit events are associated with the Snowflake identity involved in the operation.

This follows the broader Casabase Cube architecture:

Snowflake User
      │
      ▼
Casabase Cube Operation
      │
      ▼
Audit Event
      │
      ▼
USER_NAME
ROLE_NAME
SESSION_ID

Casabase Cube therefore does not need a second identity provider simply to attribute application activity.

The application’s reliance on Snowflake identity also aligns audit attribution with row-level security evaluation.

Success and Failure Logging

Section titled “Success and Failure Logging”

Auditability includes operational outcomes.

An event can record information such as:

STATUS
ERROR_MESSAGE
EXECUTION_TIME_MS
ROW_COUNT

This means the audit log can be used for more than change history.

It can also help identify:

  • Failed operations
  • Repeated errors
  • Slower operations
  • Unexpected execution patterns
  • Changes in rows processed

The Administration reference specifically recommends reviewing failures and aggregate error counts as a way to identify developing operational problems.

Audit Summary

Section titled “Audit Summary”

Casabase Cube provides an administrative summary interface:

CALL CUBE.GET_AUDIT_SUMMARY(30);

The summary provides metrics by event type such as:

EVENT_COUNT
SUCCESS_COUNT
ERROR_COUNT
AVG_EXECUTION_MS
TOTAL_ROWS_PROCESSED
UNIQUE_USERS
FIRST_EVENT
LAST_EVENT

This allows administrators to review operational trends without manually aggregating the full audit history.

Architecturally, the summary is derived from the same application-level audit history rather than from an external telemetry platform.

Audit Export

Section titled “Audit Export”

Audit information can also be retrieved through:

CALL CUBE.EXPORT_AUDIT_LOG(
    p_start_date => '2026-08-01'::TIMESTAMP_LTZ,
    p_end_date   => '2026-08-31'::TIMESTAMP_LTZ,
    p_event_type => NULL,
    p_cube_name  => 'FINANCE',
    p_limit      => 1000
);

The filters are optional, allowing the caller to retrieve audit history by:

Date Range
Event Type
Cube
Result Limit

This provides a supported way to extract application audit information for:

  • Compliance evidence
  • Operational review
  • Security investigation
  • Customer-managed archival
  • Additional analytics

Audit Data Boundary

Section titled “Audit Data Boundary”

Audit information is application-managed data.

Conceptually:

Customer Source Data
        │
        ▼
Casabase Cube
        │
        ├── Configuration
        ├── Internal Structures
        └── Audit Log

It is therefore part of the application’s internal state rather than part of the supported analytical consumption surface.

Direct integrations should not depend on undocumented internal audit-table implementation details simply because an internal object can be discovered.

For supported administrative retrieval, use documented interfaces such as:

EXPORT_AUDIT_LOG
GET_AUDIT_SUMMARY

where appropriate.

Retention

Section titled “Retention”

Audit history has configurable retention behavior.

The underlying audit history continues to grow until it is explicitly trimmed according to the customer’s retention policy.

Casabase Cube provides:

PURGE_AUDIT_LOG

for controlled removal of older records.

For example, a dry run can be performed first:

CALL CUBE.PURGE_AUDIT_LOG(365, FALSE);

This reports the records that would be removed without changing the log.

The purge can then be confirmed:

CALL CUBE.PURGE_AUDIT_LOG(365, TRUE);

Customer-Controlled Retention

Section titled “Customer-Controlled Retention”

Retention is not imposed as a provider-hosted logging policy.

The customer determines how long application audit information should be retained based on its own:

  • Operational requirements
  • Security requirements
  • Governance policies
  • Compliance obligations
  • Evidence-retention standards

If audit history must be retained longer than desired within the application, it can be exported and stored in a customer-controlled Snowflake archive before the application log is purged.

Conceptually:

Casabase Cube Audit Log
          │
          ▼
Export Required History
          │
          ▼
Customer Archive
          │
          ▼
Purge Application History

Audit History and Application Upgrades

Section titled “Audit History and Application Upgrades”

Audit history persists across Casabase Cube application upgrades.

The Native App upgrade replaces application code and can migrate or rebuild internal application structures, while customer-specific state such as:

Cubes
Dimensions
Formulas
Data
Security Rules
Classifications
Saved Queries
Schedules
Audit History

persists.

This allows audit history to span application versions.

Event Names Across Versions

Section titled “Event Names Across Versions”

Because audit history persists, event naming can occasionally reflect the version under which the event was originally written.

For example, the Administration reference notes that older audit history can contain event names such as:

HIERARCHY_CREATE
HIERARCHY_REBUILD
HIERARCHY_VIEW

while newer versions use corresponding:

DIMENSION_CREATE
DIMENSION_REBUILD
DIMENSION_VIEW

Existing rows are not rewritten during an upgrade. Reporting across application versions should therefore account for historical event names where applicable.

This is an important consequence of preserving historical audit records rather than normalizing them retroactively.

Application Logging vs. Provider Telemetry

Section titled “Application Logging vs. Provider Telemetry”

Application audit logging should not be confused with provider telemetry.

Casabase Cube records activity:

Inside Customer Snowflake

while the architecture explicitly states:

Provider Telemetry = None

Customer operational activity is not sent to an external Casabase telemetry service. The application executes within the customer’s account with no outbound connections or provider telemetry.

The architecture is therefore:

Application Activity
        │
        ▼
Internal Audit Log
        │
        ▼
Customer Account

not:

Application Activity
        │
        ▼
External Vendor Logging Platform

Compliance and Governance

Section titled “Compliance and Governance”

Audit history is one source of evidence used by Casabase Cube’s governance capabilities.

For example:

CALL CUBE.GET_PRIVACY_REPORT();

includes information about the audit log such as record count and the span of retained audit history.

Audit exports can also be used as supporting evidence for a defined review period.

For example:

CALL CUBE.EXPORT_AUDIT_LOG(
    '2026-01-01'::TIMESTAMP_LTZ,
    '2026-03-31'::TIMESTAMP_LTZ,
    NULL,
    NULL,
    10000
);

Casabase Cube provides application-level evidence. The organization’s broader compliance process remains responsible for interpreting and retaining that evidence according to applicable requirements.

Troubleshooting

Section titled “Troubleshooting”

Audit data can help determine whether unexpected behavior followed an application change.

For example:

Unexpected Query Result
        │
        ▼
Review Current Configuration
        │
        ▼
Review Recent Audit Events
        │
        ▼
Configuration Change Found?
        │
        ├── Yes ──► Validate Change
        │
        └── No  ──► Continue Diagnosis

Useful audit investigations can include:

Recent Failures
Configuration Changes
Security Changes
Query Activity
Scheduled Operations
Dimension Operations
Application Upgrades

The audit log therefore provides historical application context alongside the current-state information available through health and diagnostic functions.

Logging and Diagnostics Are Different

Section titled “Logging and Diagnostics Are Different”

Audit logging and diagnostics serve different purposes.

Audit Log
    │
    └── What happened over time?
Health / Diagnostics
    │
    └── What is the application state now?

During troubleshooting, both can be useful:

Current Health
       +
Historical Audit Activity
       │
       ▼
Operational Context

See Health and Diagnostics.

Logging and Snowflake Monitoring

Section titled “Logging and Snowflake Monitoring”

Casabase Cube audit logging is not intended to replace Snowflake account monitoring.

A complete operational or security investigation may correlate:

Snowflake Session / Query Activity
             +
Casabase Cube Audit Event
             +
Current Application Configuration

This allows investigators to understand both the underlying platform activity and the multidimensional application action it represented.

Architectural Properties

Section titled “Architectural Properties”

The logging architecture can be summarized as follows:

Property Behavior
Location Audit history remains inside the customer’s Snowflake account
Identity Activity is attributed using Snowflake user/session context
Coverage Significant administrative and data-access operations are recorded
Outcome Success, failure, timing, and row information can be recorded
Context Event-specific JSON details provide operation context
Retention Customer-controlled and explicitly purgeable
Export Supported filtered audit export is available
Upgrades Audit history persists across application upgrades
Telemetry Application audit information is not provider telemetry

Security Reviewer Summary

Section titled “Security Reviewer Summary”

For security and architecture reviews:

  • Application audit history stays inside the customer’s Snowflake account.
  • Administrative and data-access activity is recorded.
  • Audit records identify users, operations, objects, cubes, outcomes, and timing.
  • Security and query activity can be reviewed together.
  • Audit information supports review of unrestricted users in the opt-in security model.
  • Failed operations are auditable.
  • Audit retention is customer-controlled.
  • Audit history can be exported before purging.
  • Audit history persists across application upgrades.
  • Historical event names can remain unchanged across versions.
  • Casabase Cube does not send this activity to an external provider telemetry service.
  • Snowflake platform logs and Casabase Cube audit logs provide complementary layers of visibility.

Administrative and data-access activity is recorded in the application audit log inside the customer’s Snowflake account, with customer-controlled retention.

Key Principle

Section titled “Key Principle”

Casabase Cube auditability remains within the same architectural boundary as the rest of the application:

Snowflake Identity
       │
       ▼
Casabase Cube Activity
       │
       ▼
Application Audit Event
       │
       ▼
Audit History
       │
       ▼
Customer Snowflake Account

This provides application-specific operational and security history without introducing an external logging or telemetry dependency.

Section titled “Related Topics”