The CRM can copy your CRM data into your own Snowflake account on a schedule, so your analysts work from a warehouse you control. This guide takes a CRM administrator from an empty Snowflake account to a running, self-maintaining copy, and explains how to keep the sign-in healthy over time. The connection no longer needs a password or any secret that expires: the CRM signs its own access token, and Snowflake is told once to trust it.
Contents
1. Before You Start
2. Open the Snowflake Data Warehouse Page
3. Connect the CRM to Snowflake
4. Hand One Script to Your Snowflake Administrator
5. Choose What Gets Copied
6. Give the CRM Exactly the Access It Needs
7. The First Copy, and Every Day After
8. Keeping the Sign-in Healthy: Credential Rotation
9. If Something Stops Working
10. Frequently Asked Questions
1. Before You Start
You will need:
A Snowflake account, and someone who can run statements in it as an account administrator (that may be you).
In Snowflake: a warehouse and a database set aside for the CRM data. Note their names.
Your Snowflake account identifier (Snowflake shows it under your account menu; it looks like xy12345-ab67890 ).
A CRM administrator login.
Access requirements: the page is visible to CRM administrators only, and only on instances where Snowflake is switched on. If you do not see Snowflake Data Warehouse under Settings → Configuration, contact Dazos support to enable it for your instance.
The whole process at a glance. Snowflake is touched in three places only (steps 1, 5, and 9); everything else happens in the CRM.
2. Open the Snowflake Data Warehouse Page
From the CRM, open Settings → Configuration → Snowflake Data Warehouse. You can also type "Snowflake" into the search box at the top of the settings list.
The page has five cards, top to bottom:
Card | What it is for |
Connection Setup | Where Snowflake is, who the CRM signs in as, and how. |
Credential Rotation | How often the sign-in key is replaced, and the button to replace it now. |
Data Selection - Modules | Which CRM modules, fields, and related tables are copied. |
Access Scope | A read-only list of exactly what will be written, plus the permissions script for your administrator. |
Sync Schedule & Status and Sync History | How often the copy runs, and what happened on each run. |
3. Connect the CRM to Snowflake
In the Connection Setup card, fill in the details:
Field | Description | Example |
Account Identifier | Your Snowflake account, exactly as Snowflake shows it. | xy12345- ab67890 |
Warehouse | The Snowflake warehouse that will run the copy. | CRM_WH |
Database | The database that will hold the CRM tables. | CRM_DB |
Schema | The schema inside that database. | CRM_DATA |
Role (optional) | The role the sync will use. Leave the default unless your administrator asks otherwise. | CRM_SYNC_ROLE |
Username | The Snowflake user the sync runs as. This is required: it is the identity Snowflake maps the CRM's token to, so it must be the same user the setup script creates. | CRM_SYNC_USER |
Authentication Method | Leave Dazos-issued token (recommended, nothing to rotate in Snowflake) selected. The older Password option is only for accounts that were connected before this version. |
|
1. Click Save Credentials. The CRM creates its own signing key. The private half never leaves the server; only a fingerprint of the public half is shown on the page.
2. Do not click Test Connection yet: Snowflake has not been told to trust the CRM. That is the next section.
Tip: The username must match the user your Snowflake administrator creates in the next step, spelling for spelling. Upper and lower case do not matter, but a different name will fail with a message about mapping rather than about the username, so check it first if Test Connection refuses.
4. Hand One Script to Your Snowflake Administrator
Below the connection details, click Setup script ready, then open the guide. The CRM opens the Snowflake setup guide, a page written for your Snowflake administrator. It contains one script, prepared for your account, that creates the service user and its role, grants permissions on the warehouse, database, and schema you named, tells Snowflake to trust the access tokens this CRM signs, and tells it where to find the CRM's public key.
1. Click Copy setup script and send it to whoever administers your Snowflake account.
2. They run it once, using an account administrator role.
3. Come back to the Snowflake Data Warehouse page and click Test Connection. It should say Connected.
Important: The script is generated from what you saved on the page. If you change the account identifier, warehouse, schema, role or username later, open the setup guide again and re-run the parts that changed.
5. Choose What Gets Copied
Nothing leaves the CRM until you say so. In the Data Selection - Modules card, tick the modules you want copied and click Save Module Selection. Each module becomes a table in Snowflake; the table name appears next to it and can be changed before the first copy.
Control | Purpose |
Fields | Opens the field list for that module. Untick any field you do not want in Snowflake and click Save Field Configuration. |
Related | Chooses related tables (for example, a module's linked records) to copy alongside it. Click Save Related Tables. |
6. Give the CRM Exactly the Access It Needs
The Access Scope card is read-only. It lists every module, table, field count, and related table the sync will write, so you can confirm the selection before anything runs. Below the list is the Snowflake grant script: the permissions the sync user needs, and no more, written from the modules you just ticked.
1. Click Copy script.
2. Your Snowflake administrator replaces <DATABASE> with the database name and runs it once, with a role that can manage grants.
3. If you add or remove modules later, reload the page and copy the script again: it changes with the selection.
7. The First Copy, and Every Day After
In Sync Schedule & Status, choose how often the copy runs (every 1, 4, 8, 12, or 24 hours) and click Save Frequency. Then click Sync All Now to queue the first full copy.
From then on, the copy runs by itself on the schedule you chose, sending only the records that changed. Watch progress in Sync History: each run shows its date, type (full or incremental), status, how many records were sent, how many failed, and how long it took.
Tip: When a run fails, Sync History now shows Snowflake's own words for the failure, in full. Read that line first; it usually names the missing object or permission.
8. Keeping the Sign-in Healthy: Credential Rotation
The CRM's signing key never expires, but it's good practice to replace it periodically. The Credential Rotation card makes that a two-click job that needs nothing in Snowflake.
Set a schedule
1. Choose Rotate every (30, 60, 90 or 180 days, or Manual only).
2. Choose how many days before the date the administrators should be e-mailed (3, 7, or 14).
3. Click Save Schedule. The next rotation date appears on the right.
Administrators receive one email before the date and, if the date passes, a weekly reminder until it is done. Nothing stops or pauses the copy while a rotation is due.
Rotate now
1. Click Generate new signing key. The new key is published immediately so Snowflake can read it, but it is not used yet.
2. Wait a few minutes.
3. Click Rotate Now. The CRM tests the new key against Snowflake first; it switches only if that succeeds. If Snowflake has not read the new key yet, the switch is refused and the old key stays active. Try again after a few minutes.
The previous key is kept encrypted for 7 days in case you need it, then removed automatically. A running copy is never interrupted by a rotation.
9. If Something Stops Working
What you see | What it usually means | What to do |
Test Connection fails with a message about the user or mapping | The Username on the page is not the user the setup script created. | Make them match, save, test again. |
Test Connection fails right after a key rotation | Snowflake has not read the new key yet. | Wait a few minutes, then click Rotate Now again; the old key is still active in the meantime. |
Sync History shows failed runs with a Snowflake message naming a table or column | A module or field was added after the grant script was run. | Copy the grant script from Access Scope again and rerun it. |
"This feature is not available for your account" | Snowflake is not switched on for this instance. | Contact Dazos support. |
Saving fails with a message about an encryption key | The server is missing a setting it needs to store credentials safely. | Contact Dazos support; nothing on the page can fix it. |
10. Frequently Asked Questions
Q: Do I still need a Snowflake password?
No. With the Dazos-issued token, there is no password or secret anywhere. The Password method remains only for accounts connected before this version; switch to the token method when convenient, and you can forget it.
Q: What exactly does Snowflake receive?
Only the modules, fields, and related tables you ticked. The Access Scope card is the authoritative list, and it is empty until you choose something.
Q: What can the sync user do in Snowflake?
Use the warehouse, database, and schema you named, and create and write tables in that schema—nothing outside it. The grant script contains all permissions, so your administrator can see exactly what is granted.
Q: Will a rotation interrupt a copy that is running?
No. A running copy keeps the key it started with. The new key is used from the next run.
Q: How do I stop copying data?
Untick every module in Data Selection and save. To remove the connection entirely, contact Dazos support.
Q: Who gets the rotation e-mails?
Every CRM administrator with an e-mail address on your instance.
Need Help?
If you run into issues:
1. Check Sync History: the newest row shows the warehouse's own message for a failed run.
2. Click Test Connection and read the message it gives; it names the thing to fix.
3. Contact Dazos support with the message from step 1 or 2 and reference CRM-3840.