Snowflake
Connect Snowflake to DinMo with a dedicated service user, warehouse, and technical database.
Use Snowflake as the warehouse foundation for DinMo. Once connected, DinMo can query governed customer data from Snowflake to power models, segments, Customer Hub, predictions, and Identity Resolution, while writing DinMo-generated technical tables back to a dedicated Snowflake database.
Overview
A Snowflake source has two responsibilities:
read the business data that DinMo users can model and activate
store DinMo technical outputs such as segment snapshots, statistics, predictions, and Identity Resolution tables
This keeps customer data in Snowflake and makes DinMo activity easy to audit through Snowflake roles, warehouses, query history, and dedicated schemas.
Recommended setup
For new Snowflake sources, we recommend using:
a dedicated service user for DinMo
a dedicated Snowflake role with only the permissions DinMo needs
key pair authentication
a dedicated warehouse for DinMo workloads
a dedicated internal database such as
DINMO_DB
The role needs USAGE on the warehouse, SELECT access to the business schemas DinMo should read, and write access to DinMo's internal schemas. Password authentication should only be used for existing setups that have not migrated yet.
Snowflake supports service users for non-human access and key pair authentication for programmatic connections. See the Snowflake documentation for user types and key pair authentication.
Create a dedicated warehouse
Create a warehouse for DinMo workloads so you can monitor credit usage, tune sizing, and avoid impacting other workloads.
You can start with XSMALL and increase the size if queries queue or previews become slow.
Create the DinMo role, user, and internal database
Run the script below from a Snowflake role that can create users, roles, warehouses, databases, schemas, and grants. Update the values between < > before running it.
DINMO_IDENTITY is required when Identity Resolution is enabled. DINMO_PREDICTIONS is required when AI Predictions is enabled. The other internal schemas are used for segments, statistics, and snapshot storage.
Restrict access to selected schemas
The setup script above grants read access to every current and future schema in the business database. This is convenient for a first setup, but some security teams prefer schema-level grants.
To restrict access, replace the business database grants with grants like these, and repeat them for each schema DinMo should read:
If dbt or another transformation tool drops and recreates tables, keep the FUTURE grants in place on every schema DinMo needs to read.
Configure the source in DinMo
In DinMo, go to the workspace settings.
Open the Sources tab.
Click Add New Source.
Select Snowflake.
Fill in the Snowflake connection fields.

Use the values from the script:
Account identifier: the account identifier from your Snowflake URL. See Snowflake's account identifier documentation.
Database: the business database that contains the source data DinMo can read.
Internal database: the database where DinMo stores technical data. If you kept the script default, use
DINMO_DB.Warehouse: the warehouse DinMo should use. If you kept the script default, use
DINMO_WAREHOUSE.Role: the role assigned to the DinMo service user. If you kept the script default, use
DINMO_ACCESS_ROLE.Username: the DinMo service user. If you kept the script default, use
DINMO_SERVICE_USER.Authentication method: choose Key Pair.
Source name: the display name shown in DinMo.
If your account URL is https://xxx.europe-west2.gcp.snowflakecomputing.com/, enter xxx.europe-west2.gcp as the account identifier. Do not include https:// or .snowflakecomputing.com.
Configure key pair authentication
After choosing Key Pair in DinMo, click Generate a Public Key and run the generated SQL in Snowflake.

The generated SQL updates the DinMo service user with the public key used for authentication. Do not modify the generated key value.
If your security team generates the public key before the source is configured in DinMo, you can set it directly on the service user with RSA_PUBLIC_KEY.
Password authentication is not recommended for new Snowflake sources. Use it only for existing setups that have not migrated to key pair authentication yet.
Test the connection
Click Save & Test in DinMo. If the test succeeds, the Snowflake source is ready to use.
If the test fails, check the troubleshooting section below before changing the connection configuration.
Troubleshooting
Connection test fails
Check that the account identifier, warehouse, database, role, username, and authentication method match the Snowflake objects created for DinMo. If you use key pair authentication, confirm that the public key generated by DinMo was assigned to DINMO_SERVICE_USER.
The user cannot assume the role
Confirm that the role was granted to the service user:
DinMo cannot see source tables
Confirm that DINMO_ACCESS_ROLE has USAGE on the relevant database and schemas, plus SELECT on current and future tables or views. If tables are recreated by dbt or another tool, verify the FUTURE TABLES and FUTURE VIEWS grants on each relevant schema.
DinMo cannot create technical tables or views
Confirm that the internal database and schemas exist and that DINMO_ACCESS_ROLE has write access to them:
You use several databases
Create one DinMo source per Snowflake database, or make sure models use fully qualified table names such as database.schema.table.
If you still encounter an issue, contact your account manager or [email protected].
Last updated

