Before you begin

Overview

Before installing dentsu.Composable Visualize, review the prerequisites in this article to confirm that your Snowflake account, roles, permissions, data sources, and AI services are configured and ready for deployment.

Enable sharing of a Snowflake listing

To begin the installation process, our team must first enable your access to the Snowflake listing for the applicable application, which requires a few details from you regarding your Snowflake account.

If you have not already done so, contact dentsu.Composable sales to request the application.

In your request, provide the following details:

Client name - The name of the client or company related to your request.
Primary contact name
Primary contact email
Snowflake Organization Name - The unique name of your Snowflake organization, as shown in your Snowflake account details.
Snowflake Account Name - The name assigned to your Snowflake account, as shown in your Snowflake account details.
Snowflake Account Locator - The unique identifier for your Snowflake account, as shown in your Snowflake account details.

During Installation steps, the default application name will be set by dentsu. The default name for this application is DENTSU_COMPOSABLE_VISUALIZE_APP. You will have the opportunity to name the application instance within your account, but this is not required.

You can find Snowflake information in the Snowflake UI (Account > View Account Details), or by running the following in your Snowflake account:

SELECT current_organization_name() AS org_name,
       current_account_name() AS account_name,
       current_account() AS account_locator;

Snowflake account requirements

This application requires:

Snowflake on AWS. The application supports Snowflake accounts hosted on AWS. Snowflake accounts hosted on Azure or Google Cloud Platform (GCP) are not currently supported.
dentsu.Tag data. The application requires dentsu.Tag data shared from https://app.snowflake.com/merkle/merkle_4cite/. If your organization is not currently using dentsu.Tag, contact your dentsu representative to discuss implementation. Although the application can visualize other datasets, dentsu.Composable Visualize is optimized for dentsu.Tag data, and its AI capabilities are specifically trained for that data model.
Claude Sonnet 4.6 or later. Your Snowflake account must have the claude-sonnet-4-6 model, or a later supported version, enabled before using the application. You can verify this with:
```
 USE ROLE ACCOUNTADMIN;
 SELECT SNOWFLAKE.CORTEX.AGENT_RUN('{"models":{"orchestration":"claude-sonnet-4-6"},"messages":[{"role":"user","content":[{"type":"text","text":"hello"}]}],"tools":[],"tool_resources":{}}');
```
If enabled, the query should execute without an error. If not enabled, this will result in an error that the model is not enabled. Raise a Snowflake Support ticket to request it or a Snowflake account admin can enable.

The ability to run a Snowpark Container Services (SPCS) service. The Visualize app runs as a containerized service within a compute pool provisioned in your Snowflake account and is exposed through a public application endpoint. This requires the account privileges CREATE COMPUTE POOL and BIND SERVICE ENDPOINT, which are granted to the application during setup (see Account privileges below). No additional configuration is required beyond granting these privileges.

About restricted caller’s rights

Visualize runs as a container service using restricted caller's rights (RCR). Data access occurs in the context of the signed-in user, ensuring that users can view only the data their Snowflake permissions allow. To support this security model, setup includes several required grants and account settings that are generated during configuration. For more information, see Post-installation setup and verification.

Snowflake role requirements

See the Snowflake documentation for more information regarding role setup in the context of installing the application.

Before installing the application, ensure the required Snowflake roles are available and assigned to the appropriate users or administrators.

Installation role – A role with the permissions required to install the application from the Snowflake listing. Record the role used during installation, as it may be required in later configuration steps.
Enablement role (ACCOUNTADMIN or equivalent) – A role responsible for granting the required account-level privileges, running the generated setup script, and configuring required account parameters. Some actions, such as account-level grants and ALTER ACCOUNT statements, require the ACCOUNTADMIN role and cannot be performed by the application.
Chat-user role – The role assigned to end users who access and interact with the application. This role receives access to the application endpoint and the Cortex privileges required for chat functionality. We recommend creating a dedicated role for Visualize users.
Administrator role – The role responsible for managing team dashboards and application administration. This role is granted the application's administrator role (app_admin) and can be an existing account role or a dedicated role created for this purpose.

During setup, provide the names of the chat-user and administrator roles. If appropriate for your Snowflake role design, a single role can serve both functions.

Application roles defined by the app

The app itself defines two application roles. During setup, these are granted to the account roles you provide above:

Application role	Grants access to	Granted to
app_public	Chat and dashboards — every end user needs this.	your chat-user role ({CHAT_ROLE})
app_admin	Additional administration — the User Management screen and sharing Team Dashboards. Inherits `app_public`, so administrators can use the full app normally.	your administrator role ({ADMIN_ROLE})

Managing access after installation

You do not need to rerun the setup procedure to change application access. Account administrators can manage application roles from the application's configuration page in Snowsight (Catalog > Apps > [application name] > Access management).

From this page, administrators can grant or revoke application roles for additional account roles as needed. For example, you can grant the app_public role to provide chat access or grant the app_admin role to assign administrator permissions.

You can also manage application role assignments using SQL with GRANT APPLICATION ROLE and REVOKE APPLICATION ROLE statements.

App enablement requirements

The application requires several account-level privileges, object-level privileges, and account settings to operate within the Snowflake container runtime environment. During setup, the application generates the required GRANT statements automatically. Review the following requirements before proceeding with installation and configuration.

Granting account-level privileges and configuring account parameters requires the ACCOUNTADMIN role or an equivalent role with sufficient permissions.

Account-level privileges

The following privileges appear as toggles on the application's Permissions page in Snowsight. Additional object-level grants, restricted caller's rights (RCR) grants, and account parameters are generated as part of the setup process.

IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE and the SNOWFLAKE.CORTEX_USER database role, which enable access to Snowflake Cortex AI functionality.
CREATE COMPUTE POOL ON ACCOUNT, which allows the application to provision the compute pool used by its container service.
BIND SERVICE ENDPOINT ON ACCOUNT, which allows the application to expose its public chat endpoint.

Object-level privileges

The application requires access to the following customer-managed objects:

USAGE on the database and schema containing your dentsu.Tag data, and SELECT on the view registered as the application's data source. This view exists outside the application object.
USAGE on the warehouse used to run analyst queries.

Restricted caller's rights (RCR) grants

Visualize uses Snowflake's restricted caller's rights (RCR) model and accesses data using the permissions of the signed-in user. To support this behavior, the application requires additional caller-context grants that allow it to run Cortex functions and access data on behalf of authorized users.

Examples include:

CALLER USAGE ON DATABASE SNOWFLAKE
CALLER DATA READ on the source data database
CALLER USAGE on the query warehouse

The chat-user role is also granted the required Cortex roles, including CORTEX_USER, CORTEX_AGENT_USER, and CORTEX_ANALYST_USER, along with the necessary warehouse permissions. The setup procedure generates these grants automatically.

Account parameters

The following account parameters are set by ACCOUNTADMIN users:

SERVICE_CALLER_TOKEN_VALIDITY_SECS — controls how long the app may act on a signed-in user's behalf during a single session. The setup script sets this to 1800 (30 minutes). The application cannot set this parameter itself.
CORTEX_ENABLED_CROSS_REGION — only required if the AI models are not hosted in your account's region. The setup script includes this commented out; enable it only if chat fails with a "model not available in region" error. Prefer a cloud-scoped value such as AWS_US over ANY_REGION, as this is a data-residency decision.
```
 	ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_US';
```

To enable functionality

This application requires:

dentsu.Tag

About event logging

The application emits operational logs and traces that describe application activity, including performance, errors, and usage patterns, not the contents of your data. Logging is configured at info level with tracing always on.

This telemetry is written to your own account's event table and stays there. The application does not share events back to dentsu. No event sharing is configured, so nothing leaves your account. You can review exactly what the application records at any time (see below) to confirm it contains no sensitive information.

The SNOWFLAKE.TELEMETRY.EVENTS table is Snowflake's default event table. If you haven't configured a custom event table, Snowflake collects this telemetry in EVENTS by default. For how to locate and review your event table, see the Snowflake documentation, or review via the application homepage > App Events.
Review your event table at any time to see the operational events the application records (errors, warnings, traces, usage, and debug logs), all of which remain in your account.

Sharing operational telemetry with dentsu (for centralized billing and support) is not enabled today. If a future release introduces it, that will require an application update and your explicit opt-in.

Billing

Visualize incurs Snowflake compute in your own account, which appears in your account's usage:

The container service runs on a compute pool the app provisions. It can be suspended when the app is idle and resumes on the next visit. For more information, see Administrator procedures.
Analyst queries run on the warehouse you supply (the Query Warehouse reference).
Cortex AI usage (the chat agent) is billed as Cortex credits.

Observability

Snowflake's logging, tracing, and metrics provide visibility into how the application is performing within your account. This information can be used for troubleshooting, performance monitoring, and verifying that the application is operating as expected. Event data is recorded in your event table and may include Errors and Warnings, Metrics, Traces, Usage logs, and Debug logs.

During the preview period, this telemetry remains within your Snowflake account and is not shared with dentsu. If a future release introduces telemetry sharing for centralized support, it will require an application update and your explicit opt-in.