Set up a BigQuery service account key.

Before you start

• Owner or IAM Admin access on the Google Cloud project, or someone who has it.
• A decision on whether this connection needs to write to BigQuery, or only read.

Steps

1. In Google Cloud Console, go to IAM & Admin → Service Accounts → Create Service Account.
2. Give it a name you'll recognize later, something like queryflow-reader, not service-account-1.
3. Grant it BigQuery Job User (lets it run queries) and BigQuery Data Viewer (lets it read table data).
4. If this connection will write results back into BigQuery as a job destination or Data Sync target, also grant BigQuery Data Editor.
5. Open the service account, click the Keys tab, then Add Key → Create new key.
6. Choose JSON and download it. Treat this file like a password, it grants whatever access you just assigned.
7. In QueryFlow, add a BigQuery connection and set Authentication to Service Account.
8. Click Choose JSON key… and select the file, or open it and use Paste JSON instead.
9. Click Save, then Test.

Why not just three roles for everyone

Job User and Data Viewer cover almost everyone: running queries and reading results. Data Editor is a meaningfully bigger grant, it can insert, update and delete rows, so only add it to the service accounts that actually need to write, typically the connection you'll use as a Data Sync target or a scheduled job's destination. A read-only analyst connection doesn't need it.

Naming keys so future-you isn't guessing

Google Cloud lets you create more than one key per service account, and it's worth doing so deliberately rather than generating a fresh one every time you forget where the last one went. A service account named for its purpose, and a key you actually track in a password manager or secrets vault, saves you from the slow accumulation of unlabeled JSON files nobody remembers the origin of six months later.

Rotating a key without breaking a running job

If a scheduled job depends on a service account key, generate the replacement key before revoking the old one, update the QueryFlow connection, click Test to confirm it, and only then revoke the original. That order avoids a window where a nightly job wakes up to a rejected-credentials error nobody's around to fix at 6 AM.

A worked example

Say your finance team needs a connection that only ever reads a reporting dataset, feeding a scheduled query that emails a summary every Monday. Job User plus Data Viewer, scoped if you like to just that dataset with a custom IAM condition, is the full grant, nothing more. The query itself:

SELECT region, SUM(revenue) AS weekly_revenue
FROM `my-gcp-project.finance.weekly_summary`
WHERE week_start = DATE_TRUNC(CURRENT_DATE(), WEEK)
GROUP BY region;

Check it worked

Click Test in QueryFlow. A green status dot and "Connected" with a latency means the key is valid and the roles are sufficient for a basic query. If the explorer doesn't show your dataset, the roles are probably scoped too narrowly.

Troubleshooting

See the full Connect Google BigQuery tutorial for the sign-in alternative if a service account is more than you need.

Keeping more than one key around, deliberately

If you manage several QueryFlow connections for different purposes, a read-only reporting key and a separate write-capable key for syncs, keep them in separate service accounts rather than one key doing double duty. It's easier to revoke exactly the access you meant to when each key maps to one clear purpose.

Rotating on a schedule, not just when something breaks

Some teams rotate service account keys on a calendar, quarterly or annually, rather than waiting for a security review to force the issue. If that's a policy where you work, the same generate-test-revoke order from earlier applies regardless of whether the rotation is planned or reactive.

Documenting who owns which key

A short note, even just a shared doc, listing which service account belongs to which job or connection saves real time during an incident. It's the difference between rotating one key confidently and rotating three "just in case" because nobody's sure which one actually matters.