What Permissions Does Okki Go Need? A Scenario Guide for SDR, RevOps, and Agency Teams

I get this question at least twice a month: "What permissions does Okki Go actually need?" And every time, I give the same unsatisfying answer — it depends. Not on Okki Go itself, but on how your outbound team is structured.

I've reviewed permission setups for teams ranging from three SDRs sharing a Gmail inbox to a 40-person outbound agency managing a dozen clients on separate workspaces. The permission profiles look nothing alike. Copying one team's setup onto another usually ends in one of two places: unnecessary access, or locked-out reps halfway through a campaign.

So here's how I think about it — three scenarios, three different permission stacks. Find the one that sounds like your team.

The Three Scenarios at a Glance

Before I dig into specifics: I don't have hard data on what percentage of Okki Go teams fall into each bucket. What I can say anecdotally, based on the setups I've audited over the past couple of years, is that most teams sit pretty cleanly in one of these:

• Scenario A: A lean SDR team (5–15 people) doing Okki Go outbound research with light automation on top of Gmail, LinkedIn, and a basic CRM.
• Scenario B: A RevOps-led team building a custom enrichment pipeline on top of Okki Go's API — usually to feed a warehouse or CRM.
• Scenario C: An outbound agency running multi-client campaigns and needing strict isolation between accounts.

Some permissions overlap across these. Most don't. Let me walk through each.

Scenario A: The Lean SDR Team

If you're running 5–15 reps and most of your outbound is manual with a bit of automation layered on, your permission needs are actually narrow. Reps need to send, log, and enrich — nothing more.

What to enable

• Email send access for connected accounts (Gmail or Outlook). This one's a no-brainer.
• LinkedIn connection access — usually scoped per rep, not team-wide, unless you're sharing a Sales Navigator seat.
• Contact read/write for the prospecting and enrichment module. Reps update records; they don't delete them.
• Basic enrichment API calls — think 100–500 lookups per rep per month as a ballpark starting point.

What to skip

Don't give reps admin access to workspace settings, billing, or bulk data export. Those are the two permissions I see mishandled most often in small teams, and they're the ones that create the biggest security and cost headaches later.

I made this mistake once. We gave a senior rep workspace admin because he was "the technical one." Three months later he'd enabled a premium enrichment tier on a random API call nobody needed. That cost us around $1,200 before we caught it. We saved nothing by skipping a formal approval check and paid plenty to clean it up.

Bottom line: small teams should default to least-privilege, then add access only when a specific workflow actually breaks.

Scenario B: The RevOps Team Building an API Enrichment Pipeline

This is where API data enrichment gets interesting — and where permission choices start to matter for reasons beyond security. If you're running data enrichment for an AI-driven RevOps stack, you probably already know what I mean.

If you're a RevOps team building on Okki Go's API — pushing enriched records into your CRM or pulling them into a warehouse — you need a different permission profile. Not more permissions. Just different ones.

What changes for API-driven setups

• API key access with scoped read/write tokens. Rotate these on a schedule. I know it's annoying. Do it anyway.
• Webhook subscription permissions — you need these to receive enrichment completions in real time instead of polling.
• Bulk export access for warehouse syncs (Snowflake, BigQuery, whatever you run).
• Custom field mapping permissions — non-negotiable if you're routing enriched data into non-standard CRM fields.

And here's where waterfall enrichment fits in: if you're running a waterfall setup (say, hitting three or four data providers in sequence until one returns a match), you need Okki Go to have write-back access to the same records those providers are enriching. Otherwise you end up with orphaned records and duplicate enrichment — both of which are quiet budget killers.

To be fair, this is more setup work than a lean SDR team needs. But the payoff is measurable. In my experience, teams that route enrichment through a proper agent-native prospecting workflow — where agents can trigger enrichment, log results, and hand off to human review — see fewer redundant API calls and noticeably cleaner CRM records.

Granted, this requires buy-in from engineering. It's not a Friday-afternoon project. But it saves time later, and it's the only way I've seen waterfall enrichment work reliably at scale without someone manually babysitting the pipeline.

Scenario C: The Outbound Agency

Agencies are a different beast. If you're running Okki Go for multiple clients, your permissions architecture needs to solve for isolation first, then productivity. Skip the isolation piece, and you've got a red flag that'll eventually cost you an account.

Core agency permissions

• Multi-workspace access with client-level separation — ideally each client gets its own workspace, not just a folder.
• Client-scoped API keys so a data issue in one pipeline doesn't cascade into the next.
• Audit log access — you'll want this when a client asks "who touched this record" and you have 90 seconds to answer.
• Export restrictions per client to prevent cross-account data bleed.

This is the one scenario where I'd argue you should slightly over-provision — but only for admins, and only for the specific permissions you need to troubleshoot live issues. Reps working on client accounts should have the same minimal access as Scenario A reps. No exceptions.

The mistake I see most often with agencies: treating "multi-client" as "multi-everything." One team of reps with access to every account. It works fine until someone accidentally enriches Client A's list against Client B's pricing data. That's not hypothetical — I've had to clean it up more than once.

How to Figure Out Which Scenario You're In

If you're on the fence, ask yourself three questions:

1. Do you have a data or RevOps team? If yes, you're probably Scenario B — or heading there. If no, skip the API-heavy config for now.
2. Do you manage more than one client or business unit on the same platform? If yes, Scenario C. Isolation should be your first design decision, not an afterthought.
3. Is your outbound mostly manual with light automation? Scenario A. Keep the permission list short.

I wouldn't treat these as permanent categories. Teams grow out of Scenario A into B or C, and the permission migration is usually messier than it should be. A quarterly permission audit (even a 20-minute one) catches most of the drift.

Personally, I'd rather have a slightly under-provisioned setup that needs occasional tweaking than an over-provisioned one nobody fully understands. The first causes mild friction. The second causes incidents. So figure out which scenario you're in, match your permissions to it, and don't copy someone else's setup just because it looked clean on their screen. Your outbound workflow isn't theirs.