Two ways to connect your team to Quickbase (and how to pick)

If you've ever rolled out a tool that talks to the Quickbase API, you've hit this question: whose credentials does it use?

Quickbase's answer is user tokens — personal API keys that act as the person who created them. Simple enough for one person. But roll a tool out to a team and you discover the two facts that shape everything downstream:

1. Not every realm lets users create tokens. Quickbase admins can restrict token creation to specific users or groups (Admin console → Permissions). In locked-down realms, most of your team physically cannot create the token a tool would ask them for.
2. A token is exactly as powerful as its owner. There's no way to scope a user token below the owner's role — no read-only tokens, no per-table limits. The only permission boundary Quickbase offers is the role of the account that owns the token.

QVA supports two connection modes built around those two facts. Here's how each works and when to choose it.

Personal Access mode: everyone brings their own token

Each person connects QVA with their own Quickbase user token during a short onboarding. From then on, everything they do by voice happens in Quickbase as them.

Why teams choose it:

• Per-user audit history in Quickbase. Record history shows the actual person who made each change — the same as if they'd typed it.
• Quickbase roles keep doing their job. A user who can only edit the Tasks table can only voice-edit the Tasks table. Nobody can do more by voice than they could in the browser.
• No shared credential. Each token is created, owned, and revocable by its user (and by realm admins, who can see and deactivate every token in the realm).

The catch: it requires that your realm allows your users to create tokens. If token creation is restricted — common in regulated or tightly-governed realms — your team dead-ends at step one. That's what the second mode is for.

Managed Workspace mode: one connection, zero-step onboarding

Here the admin does the setup once, and the team never touches a token:

1. The admin connects the workspace to Quickbase — we recommend a dedicated service account with a role built for exactly what the team should touch, its token assigned only to the relevant app (more on this below).
2. The admin picks the tables and fields the team will use — one shared configuration for the whole workspace.
3. The admin invites the team. Members sign in and land on the dashboard. That's their entire onboarding.

Why teams choose it:

• Works in locked-down realms. Members never need permission to create tokens, because they never create one.
• Central control. One credential to provision, rotate, or revoke. One schema to maintain. New hire? Send an invite. Offboarding? Remove the member — the credential never left your hands.
• Faster rollout. The gap between "we bought this" and "the whole team is using it" is one admin session, not N individual setups.

The trade-off, stated plainly: in Quickbase's record history, changes made through a managed workspace are attributed to the service account — not the individual member. QVA keeps its own per-user command log, so you can always see who did what inside QVA, but Quickbase's native audit trail shows the shared identity. If per-user attribution inside Quickbase is a hard requirement, use Personal Access mode.

Why a service account (and not just the admin's token)

You can connect a managed workspace with your own personal token. Don't. Your token carries your permissions — usually the broadest in the realm — and every member's voice command would execute with them.

The pattern that works, and the one our setup screen walks you through:

1. Create a dedicated Quickbase user (e.g. qva-service@yourco.com).
2. Give it a purpose-built role in the target app: exactly the tables and fields your team should reach, nothing else.
3. Create a user token from that account and assign it only to that app — the one scoping lever Quickbase tokens have.
4. Connect QVA with that token.

Now the ceiling on what anyone can do by voice is a role you designed, the blast radius of the credential is one app, and rotating it is one action that never interrupts your team.

Choosing in 10 seconds

Both modes encrypt tokens with Google Cloud KMS the moment they're received, bound to their owner so a ciphertext can't be moved between records. Tokens are never stored in your browser and never leave our backend. And in both modes, Quickbase remains the source of truth for permissions — QVA is an interface, not a data store.

---

Managed Workspace mode is available on the Pro plan. Questions about which mode fits your realm's token policy? We're happy to look at it with you — sales@tryqva.com.