How to Add a Connector at the Account Level, Not Per Workspace

Why do automation platforms scope connectors to workspaces by default?

Most automation platforms ship workspace-scoped connectors because that is the safer default for multi-team companies. A workspace is the unit they bill, isolate, and audit. If Marketing connects HubSpot inside the Marketing workspace, Sales should not silently inherit that token, because the audit trail, the rate limit, and the revoke button all live with whoever added it. That isolation is a feature when you have real separation between teams, real compliance pressure, and dedicated admins for each surface. For a solo founder or a small ops team, that same default becomes friction: you connect the same HubSpot account three times across three workspaces, drift between credentials, and lose track of which token holds which scope. The platforms know this, which is why most of them ship an account-level (or organization-level, or admin-level) connector option. It is just buried two clicks deeper than the per-workspace one. Knowing where to click changes the entire shape of the build.

Where do you click to add an account-level connector?

The exact path depends on the platform, but the pattern is the same: leave the workspace view, go up one level to the account, organization, or admin area, and add the connector there. On Zapier, account-level shared connections live under Account Settings, then Shared Connections, where an admin can attach a credential and select which workspaces or teams can use it. On Make.com (formerly Integromat), an organization admin can create connections at the organization level and reuse them across teams. On n8n cloud, owners and admins add credentials at the instance level, then share them with projects. On Pipedream, accounts include a shared connected-accounts area for the workspace owner. On Sistava, this is not a separate page: every connector you add from the top-level Integrations area is tenant-wide by default, available to every team and every AI Employee inside the account.

How do you actually add an account-level connector step by step?

The flow is the same on every modern automation platform. You sign in as an admin or owner, you leave the per-workspace view, you add the credential once at the highest scope you control, then you grant the workspaces, teams, or AI Employees that need it. The reason it feels unintuitive the first time is that most onboarding flows drop you straight into a workspace, where the connector button you see only adds it at that scope. The fix is one level up. If your role inside the platform does not include account-level admin rights, you cannot do this step yourself: a workspace owner has to add the credential at the account level and grant your workspace access. If you skip the admin check and try to reauth the same service from inside the workspace, you usually end up with a second credential that quietly drifts from the first.

Add a connector at the account level

1. Sign in as account or organization owner — Workspace admin rights are not enough on most platforms. Confirm your role first; ask the account owner if you do not have access.
2. Leave the workspace view — Click your avatar or organization name in the top bar and choose Account Settings, Organization, or Admin. This is the level you want.
3. Open Shared Connections or Connected Accounts — Different platforms use different labels: Shared Connections, Organization Connections, Connected Accounts, or Integrations. Same concept.
4. Add the credential and grant scopes — Run the OAuth flow with the service account you want every workspace to use. Pick the smallest set of scopes that covers the planned automations.
5. Share with workspaces, teams, or AI Employees — Pick which child workspaces or teams can use the connector. On Sistava this is automatic: every employee in the tenant inherits the connector.

One detail that catches people: account-level does not mean unrestricted. On every platform that supports shared connections, the admin still picks which child workspaces or teams can use the credential, and most platforms log every workflow that fires through it. That is the entire point of doing it at this scope instead of duplicating. You keep one revoke button, one rate-limit budget, one audit trail, and one set of scopes to review when the security team asks. The day you rotate the underlying API key or password, you do it once and the change propagates everywhere the connector is used, instead of hunting down nine workspaces and remembering which token went where.

Once the connector lives at the account level, the next question is what consumes it. On a traditional automation platform that is a set of Zaps, scenarios, or workflows you build by hand. On an AI workforce platform that is a team of AI Employees who already know how to use the connector for their job: the Sales employee uses the HubSpot connector to log calls and update deal stages, the Marketing employee uses the Gmail connector to send sequences, the Operations employee uses the calendar to book and rebook. The connector is the plumbing; the employee is the worker. Doing the plumbing once at the account level lets the rest of the build stay focused on the work itself, not on which workspace owns which token.

What goes wrong when you scope a connector to one workspace by mistake?

Three failure modes show up in real teams that did not realize the connector was workspace-scoped. First, duplication: the same Gmail or HubSpot account ends up connected three or four times across three or four workspaces, each with a slightly different OAuth scope set, and nobody is sure which one is the source of truth. Second, drift: when someone rotates the password or the API key, only one of the connectors gets updated and the others silently break, often at 2am during a scheduled run. Third, audit pain: when the security review lands, you cannot answer the simple question of which workflows touched which CRM record, because the connector identity is fragmented across workspaces. None of these break a small team on day one, but all three compound on month three, and the cleanup is usually painful enough that founders ask the question this article answers about a quarter into the build.

When should you actually keep a connector at the workspace level?

Workspace-scoped connectors do exist for a real reason. If a single platform serves multiple legal entities, multiple clients of an agency, or multiple isolated business units inside one company, workspace scope is the right answer for any service where billing, ownership, or data residency must stay separated. An agency running campaigns for ten clients should not share one Google Ads connector across all of them: each client needs its own credential, its own scope set, and its own revoke button. The honest rule of thumb: if the underlying credential maps one-to-one to the workspace using it (one client, one connector, one revoke surface), keep it workspace-scoped. If the same credential is meant to serve everyone in the account, push it up to the account level. Most solo founders, small in-house teams, and ops teams fall in the second bucket. Most agencies fall in the first.

Frequently asked questions

There is a related question that always shows up next: once the connector is shared across the account, who or what should actually use it. On an automation platform the answer is the workflows you build by hand. On an AI workforce platform the answer is the employees you hire. The connector becomes infrastructure, and the work moves up a level: instead of designing every node, you brief a role on what to do with the access it already has. The piece below covers how that handoff actually feels when the connectors are already wired.

The takeaway is small but it saves real hours. Add the connector once, at the highest scope the platform offers, and grant from there. On Zapier that is Shared Connections, on Make that is the organization level, on n8n that is the instance, on Pipedream that is the workspace owner area. On Sistava it is automatic: tenant-wide by default, every AI Employee in the account inherits the connector without any toggle. If you are still in evaluation mode and trying to decide whether an AI workforce platform fits better than a traditional automation builder, the account-level connector model is one of the cleaner signals. When the plumbing is shared once and the employees do the work, the build stays small and the credentials stay countable. That is usually the difference between a setup that holds up at month three and a setup that quietly forks.