Skip to main content
A tenant is an isolated workspace in Zygo. Everything — flows, credentials, data tables, tickets, dashboards, and logs — lives within a tenant. Data is never shared between tenants, giving you complete separation between teams, clients, projects, or environments.

​
Creating a Tenant

Any user with tenant creation permissions can create a new workspace. The person who creates the tenant is automatically added as its first Admin. Tenant creation is controlled by two settings on the user account:
  • Can create tenants — a flag that enables or disables the ability (set by a superadmin)
  • Tenant limit — the maximum number of tenants the user can own
Superadmins can always create tenants regardless of these settings.
A common pattern is to give one person per team the ability to create tenants, and have them invite everyone else. This keeps workspace creation controlled while still being self-service.

​
Tenant Settings

Tenant admins can configure several settings that control how the workspace behaves.

​
Contact Email

A primary contact email for the tenant. Used for administrative communications and displayed in tenant management views.

​
Approved Domains

A list of email domains that are allowed to join the tenant. When configured, only users with an email address matching one of the approved domains can be invited. This prevents accidental invitations to people outside your organization. For example, setting approved domains to acme.com, acme.io means only @acme.com and @acme.io email addresses can be added as members. When enabled, users can log in to this tenant by receiving a one-time link via email instead of entering a password. This is useful for tenants where members don’t need to remember a password — such as client-facing workspaces or environments where ease of access matters more than password-based security.

​
Platform-Level Settings

Superadmins can configure additional fields that aren’t available to tenant admins:
SettingDescription
LicenseThe tenant’s license type, controlling which features and limits apply
Flow capThe maximum number of flows allowed in the tenant

​
Member Management

​
Viewing Members

All tenant members with Viewer role or above can see the full member list, including each person’s name, email, and roles. This transparency helps teams understand who has access and what they can do.

​
Adding Members

Tenant admins add members by email. When someone is added:
  1. If they already have a Zygo account, they’re added to the tenant with the assigned roles
  2. If they don’t have an account, one is created and they receive a welcome email
  3. The new member appears in the member list immediately
Admins assign roles at the time of invitation. A user can have multiple roles (e.g., both Viewer and Editor).

​
Updating Roles

Tenant admins can change a member’s roles at any time. Role changes take effect on the member’s next request — there’s no need for them to log out and back in. Common role changes:
  • Promoting a trusted team member from Viewer to Editor so they can create and run flows
  • Granting Admin to a team lead so they can manage members
  • Downgrading a departing contractor from Editor to Viewer during a transition period

​
Removing Members

Tenant admins can remove a user from the tenant. This revokes all access to the tenant’s resources immediately. The user’s Zygo account is not affected — they still have access to any other tenants they belong to.
Be careful removing the last Admin from a tenant. Without an Admin, no one can manage members or settings. A superadmin would need to intervene to restore access.

​
Tenant Isolation

Tenant isolation is a core security property of Zygo. Every resource is scoped to exactly one tenant, and the authorization system enforces this at every level:
  • Database queries are always filtered by tenant ID — a user in Tenant A can never see or modify a resource belonging to Tenant B, even by guessing its ID
  • Roles are per-tenant — being an Admin in one tenant gives you zero access to another
  • Credentials are tenant-scoped — API keys and secrets stored in one tenant are invisible to all other tenants
  • Data tables are isolated — two tenants can have a table called customers with completely separate data
The only exception to tenant isolation is superadmins, who can access any tenant for platform administration purposes.

​
Switching Tenants

Users who belong to multiple tenants can switch between them using the tenant selector in the navigation. Switching tenants changes the entire context — the sidebar, flows, data tables, tickets, dashboards, and all other resources update to show the selected tenant’s data. The currently active tenant is stored in the user’s session. Refreshing the page or returning later keeps you on the same tenant.

​
Deleting a Tenant

Tenant admins can delete a tenant from the tenant settings page. This is a permanent, irreversible action.
Deleting a tenant permanently destroys all of its data — every flow, credential, data table, ticket, dashboard, and log within the tenant. This cannot be undone. Consider deactivating individual resources or removing members instead if you want to preserve the data.

​
Common Tenant Patterns

Each department or team gets their own tenant. Marketing has their automation flows, Engineering has their monitoring dashboards, and Sales has their lead tracking. Members can belong to multiple team tenants if they need cross-functional access.
Agencies and service providers create a tenant for each client. This guarantees client data is completely separated, and you can invite clients as Viewers to see dashboards without exposing internal flows or credentials.
Use tenants to separate development, staging, and production workflows. Build and test flows in a dev tenant, then recreate them in production when ready. This prevents accidental runs against live data.
Give each user a personal tenant for experimentation, plus a shared team tenant for production workflows. Users can prototype flows in their personal space and move proven ones to the shared tenant.