The CRM can copy your CRM data into a Databricks workspace on a schedule. This guide takes a CRM administrator through connecting to Databricks, choosing what is copied, and keeping the sign-in healthy. The recommended way to sign in is with a Dazos-issued token: the CRM signs its own short-lived token, and Databricks is told once, through a federation policy, to trust it. There is no secret to store and nothing that expires.
Contents
1. Before You Start
2. Open the Databricks Data Warehouse Page
3. Enter the Connection Details
4. Choose How the CRM Signs In
5. Register the CRM in Databricks (Dazos-issued token only)
6. Save and Test
7. Choose What Gets Copied, and When
8. Rotating the Signing Key
9. If Something Stops Working
10. Frequently Asked Questions
1. Before You Start
You will need:
A Databricks workspace with a SQL warehouse, and the warehouse's HTTP path (in Databricks: SQL Warehouses → your warehouse → Connection details).
A service principal in that workspace, with permission to use the SQL warehouse and to create tables in the catalog and schema you choose. Note its Application ID.
Someone who can add a federation policy to that service principal (a workspace or account administrator; that may be you).
A CRM administrator login.
Access requirements: the page is visible to CRM administrators only, and only on instances where Databricks is switched on. If you do not see Databricks Data Warehouse under Settings → Configuration, contact Dazos support to enable it for your instance.
2. Open the Databricks Data Warehouse Page
From the CRM, open Settings → Configuration → Databricks Data Warehouse, or type "Databricks" or "warehouse" into the settings search box.
The page has these cards, top to bottom:
Card | What it is for |
Connection Setup | Where Databricks is, which service principal the CRM signs in as, and how. The signing key and rotation buttons live here too. |
Data Selection - Modules | Which CRM modules, fields, and related tables are copied. |
Sync Schedule & Status and Sync History | How often the copy runs, and what happened on each run. |
3. Enter the Connection Details
In Connection Setup, fill in:
Field | Description | Example |
Workspace URL | Your Databricks workspace address, as shown in the browser when you are signed in. | dbc-12345678- abcd.cloud.databricks.com |
HTTP Path | The SQL warehouse's HTTP path from its Connection details tab. | /sql/1.0/warehouses/abc123def456 |
Catalog | The Unity Catalog catalog that will hold the CRM tables. | main |
Schema | The schema inside that catalog. | crm_data |
Authentication Method | See the next section. |
|
4. Choose How the CRM Signs In
Method | What it is | When to use it |
Dazos-issued token (recommended, no secret to rotate) | The CRM signs a short-lived token with its own private key and exchanges it for a Databricks token when it connects. You register the CRM once, on the service principal, as a trusted issuer. Nothing is stored in two places, and nothing expires; the CRM rotates the key entirely internally. | Any new setup. |
Personal access token (legacy) | A token created in Databricks and pasted into the CRM. It has an expiry date set in Databricks; when it expires, the copy stops until you create a new token and paste it here. | Setups connected before this version. |
With the Dazos-issued token, also fill in Service principal Application ID: the Application ID of the service principal the CRM will act as. With a personal access token, paste it into Personal Access Token; after saving, the field shows only asterisks, and typing a new value replaces the old one.
Tip: A connection set up before this version with a service principal's client ID and secret keeps working as it is. When convenient, switch to the Dazos-issued token and retire the secret.
5. Register the CRM in Databricks (Dazos-issued token only)
1. With the token method selected, click Generate signing key. The page confirms a key is in place and shows its fingerprint.
2. The box Register this in Databricks now shows the values a federation policy needs: issuer, subject and audience, plus where Databricks can read the CRM's public keys. Copy them rather than retyping; they are matched exactly.
3. Have your Databricks administrator add a federation policy on the service principal with those values. The policy goes on the service principal, not on the whole account: Databricks itself advises against account-wide federation with an issuer the account owner does not control, which is what this CRM is to them.
4. Alternatively, click Copy the command and run it with the Databricks command line while signed in as an administrator; it creates the same policy.
6. Save and Test
1. Click Save Credentials.
2. Click Test Connection. Give Databricks a minute after creating the policy before the first test.
If sign-in is refused, the message next to the button shows Databricks' reason and names the three values to check in the policy. It never shows a token or secret.
7. Choose What Gets Copied, and When
Nothing leaves the CRM until you choose it:
1. In Data Selection - Modules, tick the modules to copy and click Save Module Selection. Each module becomes one table in the schema you named. Use Fields to leave individual fields out (Save Field Configuration) and Related to include related tables (Save Related Tables).
2. In Sync Schedule & Status, pick a frequency (every 1, 4, 8, 12, or 24 hours), click Save Frequency, then Sync All Now for the first full copy.
3. Watch Sync History: each run shows its date, type, status, records sent and failed, and duration. When a run fails, Databricks' own message is shown in full.
8. Rotating the Signing Key
The CRM's signing key never expires, but good practice is to replace it now and then. It is a two-step job that needs nothing in Databricks once the policy is in place.
1. Click Generate next key. The next key is published immediately so Databricks can read it, but it isn't used yet.
2. Wait a few minutes.
3. Click Rotate now. Databricks tests the new key first; only if that works does it take over. If Databricks has not read it yet, the switch is refused and the current key stays active. Try again after a few minutes.
The previous key keeps working for a grace period, then is removed automatically. A running copy is never interrupted by a rotation.
Note: a rotation schedule with e-mail reminders is available on the Snowflake and Microsoft Fabric pages and is planned for Databricks. Until then, rotation here is manual: the two buttons above.
9. If Something Stops Working
What you see | What it usually means | What to do |
Test Connection refused with a Databricks message about the token or client | The federation policy doesn't match the issuer, subject, and audience shown on the page, or it was applied to the account instead of the service principal. | Re-check the policy against the values on the page. |
Test Connection fails right after a key rotation | Databricks has not read the new key yet. | Wait a few minutes and click Rotate now again; the old key is still active meanwhile. |
Sync History shows failed runs naming a catalog, schema, or table | The service principal lacks a permission on the object named. | Grant it use of the catalog and schema, and permission to create and write tables there. |
Copy stopped after a date (personal access token) | The token expired in Databricks. | Create a new token in Databricks, paste it into Personal Access Token, save; or switch to the Dazos-issued token. |
"This feature is not available for your account" | Databricks isn't enabled 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 personal access token?
No. With the Dazos-issued token, you don't need to create a token or secret in Databricks or paste anything anywhere. The legacy option remains for connections made before this version.
Q: Why a policy on the service principal rather than on the account?
A policy on the account would let the CRM act as any principal; one on the service principal limits it to that identity and the permissions you gave it. Databricks recommends the narrower form for an issuer the account owner does not control.
Q: What exactly does Databricks receive?
Only the modules, fields, and related tables you ticked in Data Selection. Nothing else.
Q: Will a rotation interrupt a copy that is running?
No. A running copy keeps the credential 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.
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 names the thing to fix.
3. Contact Dazos support with that message and reference CRM-3840.