Organizations & roles

Workspaces: personal vs extra

Every user gets a personal workspace automatically at signup. On the cloud you name it on the first onboarding step; the name is built from your display name until you type your own (for example “Alex's Workspace”), and on a self-hosted install it starts with that default. You can rename it at any time. You are its OWNER and it is your default workspace. The personal workspace is special: it is never paused, it can never be deleted, and it never expires.

On Pro, Team, and Enterprise, an owner can create extra workspaces beyond the personal one. Switching into one is an explicit action, never automatic. An extra workspace does not start a new subscription: it shares the owner's plan, so members you invite into it draw from the owner's credit wallet (subject to any per-member quota you set, see below).

Storage is one shared pool per account. The plan's storage allowance belongs to the owner's account, not to each workspace: what is stored in every workspace the owner owns is added up. Once the pool is full, every one of those workspaces refuses new files, including a workspace that has stored nothing itself. See Plans & billing for the allowance of each plan.

You manage all of this in Settings > Organization, which has four tabs: Members, Workspaces, Security, and Advanced.

Creating, switching, deleting, and restoring workspaces

How many workspaces you can have is capped by your plan. The count includes the personal workspace:

Creating one over the cap fails with WORKSPACE_LIMIT_REACHED. Switching changes which workspace you land in. On the cloud, after switching to a different workspace you wait a few seconds (5 by default) before you can switch again; re-selecting the one you are already in never counts. The self-hosted Community Edition has no switch cooldown.

Deleting a workspace other than the personal one requires typing its exact name to confirm, and only the OWNER can do it. Deletion is soft: the workspace disappears from your switcher, its pending invitations are cancelled, and any member whose default was that workspace is moved to one that still exists, but the data is kept during a grace window.

1. 1
   Delete
   The OWNER deletes the workspace with the matching confirmation name. It is hidden immediately but not yet gone.
2. 2
   Grace window (30 days by default)
   The workspace, its data, and its audit trail stay intact. The OWNER can restore it at any time during this window.
3. 3
   Restore, or permanent purge
   If the OWNER restores it, it reappears as it was. If nobody restores it before the window closes, a daily cleanup permanently removes its data. Billing and audit history stay valid after the purge.

If you downgrade below your current workspace count, the extra workspaces beyond the new cap (never the personal one) are paused rather than deleted: nobody, including the owner, can enter them, but their data is kept. Upgrading again un-pauses them automatically.

Roles: the permission matrix

Every membership has exactly one of four roles. MEMBER is the default when someone is invited without choosing a role.

Note: an ADMIN can remove a MEMBER or VIEWER, but not another ADMIN and never the OWNER. Nobody can remove themselves: use leave instead.

Inviting members

An OWNER or ADMIN invites by email and role with Invite Member on the Members tab. The role defaults to MEMBER, and you cannot invite someone as OWNER. Inviting requires a Team or Enterprise plan; on any other plan you get a “Current plan does not support team members” error.

Each plan also caps total members (current members plus pending invitations):

Inviting someone who is already a member, or who already has a pending invitation, is rejected. To prevent abuse, one person can send at most 20 invitations per hour and a workspace at most 50 per hour; hitting either limit is recorded in the audit log.

Invitation lifecycle

An invitation is PENDING, ACCEPTED, EXPIRED, or CANCELLED. There is no separate “declined” status: declining moves it to CANCELLED. Invitations expire 7 days after they are sent.

Every invitation needs an explicit accept: nobody is added silently. Accepting re-checks capacity at that moment, so an invitation can still be refused if the workspace was deleted, the team plan lapsed, or the member cap filled up in the meantime.

Changing roles, removing members, and leaving

Only the OWNER can change a member's role, and not their own role, and never to OWNER.

Everyone except the OWNER can leave a workspace. An owner who tries gets OWNER_CANNOT_LEAVE. If the workspace you leave was your default, your next-oldest remaining membership becomes your default automatically.

Per-member resource restrictions

Beyond roles, an OWNER or ADMIN can fine-tune what a specific MEMBER or VIEWER can reach, resource by resource, with Manage Access on the Members tab. Each resource has one of three levels:

You can restrict workflows, applications, interfaces, agents, datasources, projects, files, and skills, one at a time or in bulk (Allow all, Block all). Restrictions set on an OWNER or ADMIN are ignored.

Member quotas

An OWNER or ADMIN can also cap how much a member consumes, with Manage quota, on up to three independent dimensions: credits, storage, and LLM tokens. An unset dimension has no cap. Caps reset on the same monthly cycle as the owner's subscription, and there is one cap configuration per member.

Audit log

OWNER and ADMIN can read the workspace audit log on the Security tab: newest first, paginated, and filterable by event type. Each entry shows who did it and to whom.

ORG_MEMBER_INVITED · ORG_INVITE_ACCEPTED · ORG_INVITE_CANCELLED · ORG_INVITE_RATE_LIMITED
ORG_MEMBER_REMOVED · ORG_MEMBER_LEFT · ORG_ROLE_CHANGED · ORG_OWNERSHIP_TRANSFERRED
ORG_DELETED · ORG_RESTORED · ORG_PURGED
ORG_QUOTA_CAP_SET · ORG_QUOTA_CAP_REMOVED · ORG_QUOTA_CAP_EXCEEDED
ORG_SAML_SSO_CONFIGURED · ORG_SAML_SSO_DELETED · ORG_SAML_SSO_MEMBER_JOINED
ORG_SSO_DOMAIN_ADDED · ORG_SSO_DOMAIN_VERIFIED · ORG_SSO_DOMAIN_REMOVED

The audit trail survives a permanent purge (the purge itself is recorded as ORG_PURGED), so history stays readable after the data is gone.

Workspace avatar

A workspace can carry one avatar image (JPEG, PNG, GIF, or WebP, up to 5 MB), uploaded or replaced by an OWNER or ADMIN. Removing it falls back to an image with the workspace's initials, so there is never a broken image. A new upload or a rename shows up everywhere right away.

SAML SSO

A workspace can connect its own SAML identity provider (IdP). SAML users are added as workspace members on their first login. Setting it up has two parts: the connection, and at least one verified email domain.

Connect your identity provider

1. 1
   Open the SAML SSO panel
   Go to Settings > Organization, then the Security tab.
2. 2
   Enter the IdP details
   Fill in Provider name, IdP entity ID, Single sign-on URL (HTTPS; plain HTTP is accepted only for localhost), and the X.509 signing certificate. When you edit an existing connection, leave the certificate blank to keep the current one. Then click Save SSO.
3. 3
   Configure your IdP
   Copy the Service provider details into your IdP: SP entity ID, ACS URL, and Metadata URL. The panel also shows the Workspace SSO URL (a direct sign-in link for this workspace) and the Certificate fingerprint.
4. 4
   Verify at least one email domain
   See the next section. Until a domain is verified, nobody can join through SSO.

With Hide from the global login page, users sign in through the Workspace SSO URL instead of seeing a button for your workspace on the shared login page.

Verify your email domains

SSO sign-in works only for addresses on a domain this workspace has proven it owns. You prove it with a DNS TXT record, in the Verified email domains list of the same panel.

1. 1
   Add the domain
   Type the domain (for example company.com) and click Add domain. It shows as Pending, with the record to publish.
2. 2
   Publish the TXT record
   At your DNS provider, add a TXT record with the Name and Value the panel shows. The name is _livecontext-sso. followed by your domain, and the value starts with livecontext-sso-verification=. The record sits on its own name, so it never touches your domain's other TXT records such as SPF.
3. 3
   Click Check now
   When the record is found, the domain shows as Verified. DNS changes can take a few minutes to appear: if the record is not visible yet, you are told so and can check again later.

• A workspace can list at most 20 domains.
• A domain can be verified by only one workspace.
• A new member can join through SSO only when the email their IdP sends is on a verified domain. Otherwise sign-in is refused with “This email address is not on a domain verified for this workspace's SSO”. People who are already members keep signing in as before.
• Joining through SSO still respects the team plan and the member cap. If the connection is not active, or the workspace was deleted, sign-in is refused.

How people sign in with SSO

On the LiveContext sign-in page, a person chooses Sign in with SSO and enters their Work email. If the email is on a verified domain of a workspace whose connection is active, they are sent to that workspace's identity provider. Otherwise they see “No SSO is set up for this email domain. Sign in another way, or ask your workspace admin.” People can also go straight to your Workspace SSO URL.

Signing in: cloud vs self-hosted

The Community Edition can close public registration after setup. An invite link with a valid pending invitation still lets that specific person register. See Self-hosting.

Troubleshooting

Related pages