Command Palette

Search for a command to run...

Access levels (Console, Studio, IIA)

How permissions work across the three Insites surfaces — what each access level can see and do, and which level to grant when inviting a teammate or client.

Insites has three surfaces, and an account can hold a different access level on each. When you invite someone from the Studio members page, you are choosing the surface(s) they can sign into and what they can do once they're there. This page explains every level so you can pick the right one.

The three surfaces#

SurfacePurposeWho it's for
ConsoleThe agency / account control plane. Manages instances, billing, domains, environments, agency-wide users, and the marketplace. One Console account can hold many instances.Agency owners, account admins, billing managers.
StudioThe AI build surface. Browser-based editor, chat-driven generation, design pipeline, deploy. Operates against a connected instance.Developers, designers, technical builders.
IIA"Insites Instance Admin" — the per-instance admin UI for content, CRM, data, events, forms. No code, no AI. The end-user-facing admin that ships with every Insites site.Client editors, content managers, end-user operators.

Access levels at a glance#

The three levels stack: granting Console implies the user can also reach Studio and IIA for instances they have access to. Studio implies IIA on the same instance. IIA-only never reaches Studio or Console.

Console access#

Full agency-wide control. A Console member can:

  • Create, archive, suspend, and migrate instances
  • Manage billing, plans, payment methods, and invoices
  • Add and remove members across the agency, set roles, and revoke access
  • Configure domains, environments, and integrations at the account level
  • Browse and install marketplace templates and modules
  • Open Studio for any connected instance and act with full Studio permissions
  • Open IIA for any connected instance and act with full IIA permissions

Grant Console only to people who need to manage the agency itself. Most teammates do not need this level.

Studio access#

Build and deploy against connected instances. A Studio member can:

  • Open the Studio editor on instances they're added to
  • Use AI chat, generate code, edit files, manage branches
  • Deploy, view deploy history, and roll back
  • See per-instance activity, comments, and member changes
  • Reach IIA on the same instance with full content access

Studio members cannot manage billing, create new instances, or change agency-wide settings.

IIA-only access#

Day-to-day content and data work on a single instance. An IIA-only member can:

  • Sign into the per-instance admin and edit content via the modules they're granted (CMS, CRM, Data, Events, Forms, etc.)
  • Be scoped down to specific modules or records by an admin
  • Cannot open Studio, cannot deploy code, cannot reach Console

IIA-only is the right level for client-side editors, content marketers, and event coordinators who shouldn't see code or billing.

How to choose when inviting#

  • A developer or designer joining your team: Studio. Add Console only if they will manage billing or agency-wide settings.
  • A client editor or marketer: IIA-only.
  • A second account admin / partner: Console.
  • A contractor working on one project: Studio, scoped to the specific instance.

You can always upgrade or revoke access later from the members page.

What happens on the underlying systems#

  • Console access is held on the agency record. Issued and revoked from console.insites.io.
  • Studio access is held per workspace and per connected instance. Issued from the Studio members page.
  • IIA access is held per instance and per module. Issued from the instance's own admin or by a Studio / Console member.

A single Insites account (one email) carries all three levels. A teammate signs into each surface with the same credentials and sees only what they're entitled to.