Skip to main content
A consultant signs in on Monday, picks one client from the org switcher, and the entire workspace becomes that client’s: their leads, their agents, their conversations, their bill. An hour later she switches to the next client and the screen behaves as if the first one never existed. That clean line is the organization — the boundary Apollo Space, the AI operating system for your company, draws around everything. It’s what lets one login hold three clients, or three business units, without anyone ever second-guessing whose data is on screen.

​
What is an organization

An organization (or org) is Apollo Space’s tenant: the boundary where data, agents, integrations, and billing live. Every resource you create — a lead, an agent, a conversation — belongs to exactly one organization.
A user can belong to multiple organizations (e.g., a consultant serving three clients). Apollo Space never mixes them: when you switch orgs in the menu, all on-screen context updates to reflect that tenant.
Apollo Space is in invite-only access. The Apollo Space team grants your initial access (reach out through official channels). From there, onboarding is self-serve — you create your company’s org directly in the app and invite your team. There is no public sign-up.

​
Role model

Within an org, each member has a role that defines what they can do:
RoleWhat they can do
OwnerEverything — including changing plans, deleting the org, and adding/removing members
AdminConfigure agents, integrations, and pipelines; view the entire org
MemberDay-to-day operations (create leads, chat with agents, launch campaigns)
ViewerRead-only — useful for auditors or external stakeholders
Invitations are sent by email. See Invite your team for step-by-step instructions.

​
Data isolation — true multi-tenancy

This section covers the technical/security details. If you just want to use Apollo Space, you can skip it — but it’s worth knowing it exists.

​
Isolation enforced at the database layer

Every Apollo Space table that holds customer data is protected by a database-level rule that only allows reading/writing rows belonging to the active org in that session. In practice: even if an application bug forgets to filter by org, the database refuses the access.

​
Why this matters

  • No cross-bleed: a slip at the application layer still cannot leak data between orgs — the database intercepts it.
  • Auditable: your company’s security team can verify the model directly, without relying on a contractual promise.
  • SOC-ready: the design is audit-friendly and can be reviewed by an external assessor.

​
Different contexts within the same org

An organization has three logical contexts that appear in the UI:

Workspace (shared)

Where the entire team operates. Leads, pipelines, org-scoped agent conversations, documents. The default for most screens.

Personal space

Each member has their own space (notes, test traces, personal integrations — e.g., their own team’s Notion).

Digital Twin

A leader’s “twin” agent — represents their decisions and voice in conversations they won’t mediate directly. See Digital Twins.

​
Per-org limits

An organization has its own budget in Stars and its own spending caps. Nothing that happens in one org affects the balance of another — even if the same user belongs to both.

​
Next steps

Agents

Each org has its own agents. See how they work.

Multi-tenant security

Technical detail on the isolation model — for security teams.