Workspaces, Organizations, and Data Isolation

Learn how personal workspaces, organizations, member roles, resource sharing, API keys, and wallets are isolated.

UnieAI Studio uses a workspace as the main user-facing resource boundary. Every user has a personal workspace and can create or join one or more organizations. The workspace selected in the sidebar determines the scope shown on model, knowledge-base, SQL database, skill, API-key, wallet, and other asset pages.

An Organization in the Studio UI is a non-personal workspace. The database Tenant, Project, and Group records are implementation details; they do not represent a user-configurable Tenant → many Projects → many Groups hierarchy.

Personal workspace

A personal workspace is prepared with the user account. Its main properties are:

Resources are primarily owned by the user and personal workspace
Personal API keys resolve model access as that user
Runtime usage is paid from the personal wallet
Supported resources can be shared directly with another user or organization
A personal workspace has no organization invitations or organization member roles

Switching to an organization does not move personal assets into it. To let an organization use a personally owned resource, use that resource's sharing, entitlement, or Marketplace adoption workflow.

Organization workspace

An organization is a workspace for shared resources and a shared wallet. Its creator receives the creator role. Other members join through invitations and receive an organization role.

Organization resources can include:

Custom models
Knowledge bases and the workspace dataset
SQL database connections
Skills
API keys
Deployments, machines, and other licensed workspace features

The ability to create or manage a resource depends on member role, platform status, license, quota, and resource-level permission. Membership alone does not grant edit access to everything.

Three permission layers

Studio evaluates platform role, organization role, and resource-level permission together.

Rendering Mermaid diagram…

Platform roles

Role	Main purpose
`super_admin`	Full platform and system administration
`admin`	Platform administration features
`pro`	Pro default features and quotas
`user`	Standard-user default features and quotas
`pending`	Awaiting approval; cannot create organizations or normal personal API keys and other restricted resources

A platform role controls platform features, administrative UI, and default quotas. It is not a permanent ACL for every business resource. Platform administrators can have additional visibility for administration; ordinary users still pass workspace and resource checks.

Organization roles

Role	Organization-level ability
`creator`	Manage organization name, membership, roles, invitations, and supported organization settings
`collaborator`	Edit the name, invite members, manage ordinary users, and use organization resources
`user`	Use authorized organization resources but not change organization settings, roles, or invitations

Creators and collaborators can normally create and manage organization resources, but individual features still perform additional checks. SQL connections, deployments, or high-risk operations can also require a license or feature-specific authority.

Resource-level permissions

Custom models, knowledge bases, skills, and similar resources can separately identify:

Owner or creator
Collaborators who can edit
Users who can use but not manage
Other organizations that can use the resource
Marketplace publication or adoption status

An organization user can therefore edit one resource if explicitly made its collaborator. Conversely, someone who manages their own organization cannot automatically edit a resource another organization only shared for use.

Resource scopes

Resource	Primary scope	Additional isolation
Custom model	Personal workspace or creating organization	Collaborators, allowed users, allowed organizations, visibility
Knowledge base	Project backing the personal or organization workspace	Owner, collaborators, user and organization sharing, Marketplace
Skill	Personal workspace or organization	Collaborators, allowed users or organizations, versions, Marketplace entitlement
SQL database	Workspace and creator authority	Connection ACL, allowed operations, and write policy
API key	Personal account or organization Project	Owner or organization role, expiry, enabled state, rate and usage limits
Request Logs	Billing and execution Project	Personal, organization-member, or platform-admin visibility
Wallet	Personal account or non-personal organization	Separate ledger, reservations, and top-up authority

Visibility in an asset list, runtime use, and configuration editing are distinct permissions. The runtime checks again whether the user or organization represented by the API key may use the requested model and its bound resources.

API-key isolation

Personal API keys

A personal-workspace key is stored in user API-key scope. The runtime resolves model access as the owner and charges usage to the personal wallet.

Organization API keys

An organization key belongs to the internal Project backing that organization. Organization creators and collaborators can create and manage it; ordinary users have only the visibility currently allowed by the UI and permission checks. The runtime authorizes only models available to that organization and charges billable usage to its organization wallet.

Do not reuse one key across organizations. Create separate keys for development, testing, production, and different applications so usage can be attributed, limited, and revoked correctly.

See API Key Management for the operational workflow.

Wallet and usage isolation

Personal and organization wallets are separate billing boundaries:

Personal keys and personal-workspace requests use the personal wallet
Organization keys and organization runtime requests use the organization wallet
Request Logs and usage summaries retain project, API-key, model, and request attribution
Organization role and platform authority determine who can view or top up an organization wallet

A member's unrelated personal usage does not become organization-funded merely because they joined the organization. The key and workspace resolved for each request determine its billing target.

Quotas are configurable

The platform can define different defaults for super_admin, admin, pro, user, and pending, including:

Whether organizations can be created and how many
Total organization members
Allowed users
Collaborators
Total custom knowledge-base capacity and per-file size

Administrators can change role defaults and apply per-user overrides. This documentation therefore does not present a permanent plan-quota table. Use the limits shown by the current Studio deployment and administrator settings. Exceeding a limit normally blocks creation or expansion; it does not mean existing resources are deleted automatically.

Organization deletion and shared resources

Organization deletion is currently a restricted development feature. It cleans up resources created in and owned by that workspace, such as custom models, knowledge bases, and skills. A resource owned elsewhere and merely shared with the organization should not be treated as organization-owned content to delete.

Organization deletion is destructive. Do not infer its result from database Tenant cascade rules. Before running it, review the UI warning, affected resources, backup requirements, and Marketplace adoption relationships.

Internal data model

The system internally uses Tenant, Project, and Group records for runtime, API keys, billing, and logs:

Every personal and organization workspace has a corresponding Group
Each Group currently maps to one Project, which carries API-key, log, and selected data scopes
A Project belongs to an internal Tenant container
A non-personal Group is what the user sees as an organization

These relationships describe current storage; they are not a public commitment to a user-configurable organization hierarchy API. Users should work with workspaces, organizations, and resource permissions.