Create a Databricks personal access token.

Before you start

• A Databricks account with access to the SQL warehouse you want to connect.
• A note of how long you want the token to live, some workspaces set an expiration policy.

Steps

1. In Databricks, go to Settings → Developer → Access tokens.
2. Click Generate new token.
3. Give it a label you'll recognize later, like queryflow-desktop.
4. Set an expiration if your workspace allows one, or leave the default.
5. Click Generate, then copy the token immediately, it won't be shown again.
6. In QueryFlow, add a Databricks connection (or edit an existing one).
7. Under Authentication, choose Personal Access Token.
8. Paste the token into Personal Access Token and click Save.

Check it worked

Click Test. A green status dot and "Connected" with a latency confirms the token is valid and has access to the warehouse you pointed it at.

Token vs. service principal

A personal access token is tied to your Databricks user account, it's the quickest path and fine for a connection only you'll use. A service principal is a machine identity with its own Client ID and Client Secret, better for a scheduled job or a shared connection that shouldn't break when your password changes or you leave the team. If you're setting this up for a report that runs every morning regardless of who's around, a service principal is the safer bet.

A worked example

Once connected, confirm access with something simple before building anything on top of it:

SELECT current_user(), count(*) AS visible_tables
FROM system.information_schema.tables;

If that returns a row, the token is working and has at least read access to the metadata catalog.

Troubleshooting

Rotating a token without breaking anything

When a token's expiration approaches, generate the replacement before the old one lapses, then update the QueryFlow connection and click Test to confirm the new one works, before letting the old one expire. Doing it in that order means a scheduled job never has a window where both are invalid.

Storing the token somewhere other than your memory

A password manager or a team secrets vault beats a note in Slack or a text file on the desktop. If more than one person might need to regenerate this token later, document where it's used, QueryFlow, a script, a dashboard, so rotating it doesn't quietly break something nobody remembered depended on it.

A worked check after rotating

After updating the token, run something simple before trusting anything scheduled against it:

SELECT current_user();

If that returns your account, or the service principal's identity, the new token is live and working.

Setting an expiration you'll actually remember

A token with no expiration is one less thing to think about today and one more thing to forget entirely. If your workspace allows setting an expiration, pick something realistic, 90 days is common, and put a reminder somewhere you'll actually see it before the token lapses on a job you rely on.

Documenting who owns which token

A short note listing which token or service principal belongs to which job saves real time during an incident. It's the difference between rotating one credential confidently and rotating three "just in case" because nobody's sure which one actually matters.

It is a small habit, but it is the kind that only pays off exactly when you need it most.

Where a service principal fits better than a token

A service principal makes more sense than a personal token once more than one person or one automated job depends on the same connection. It's independent of any single Databricks user account, so it keeps working even if the person who originally set it up changes teams or leaves.

Naming a service principal for its purpose

Name it for what it does, "nightly-reporting-sync," not who created it. That way a teammate looking at Databricks admin months later understands what depends on it without having to ask around.