> For the complete documentation index, see [llms.txt](https://docs.unitlab.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unitlab.ai/documentation/workspaces/capacity-limits-and-workspace-operations.md).

# Capacity, limits, and workspace operations

Workspace operations keep growth visible. Capacity is not only storage or subscription—it also includes queue backlog, review availability, model throughput, failed batches, release processing, and privileged-owner coverage.

Statistics appear at project and member levels. Current surfaces include:

* project overview charts;
* monthly progress;
* daily time series;
* overall progress;
* average time per item;
* total working time;
* issue counts;
* annotator and reviewer breakdowns;
* member heatmaps and summaries;
* workspace member statistics pages.

Some statistics and premium role experiences depend on the workspace subscription. Statistics should be interpreted with workflow context—for example, faster annotation can coexist with higher reviewer rejection and should not be reported as improved productivity in isolation.

### 19. Accounts, workspaces, members, roles, and permissions

### Authentication and account recovery

Unitlab supports email/password sign-up and sign-in, Google authentication, email verification, invitation-token access, password reset, and TOTP two-factor authentication.

Two-factor authentication includes QR/secret setup, verification, ten single-use backup codes shown once, login challenge, disable, and backup-code regeneration. When 2FA is enabled, password change, password-reset completion, account deletion, and workspace destruction require an appropriate second factor.

If a user refreshes during the temporary 2FA login challenge, the challenge is cleared and the user returns to login rather than leaving reusable sensitive state in the browser.

### First-workspace onboarding

1. The user authenticates.
2. If no workspace exists, Unitlab opens the workspace wizard.
3. The user selects a purpose: Work, Education, or Personal.
4. The user enters a workspace name.
5. The user can optionally invite teammates.
6. Unitlab creates the workspace, makes the user Owner, provisions the free subscription, and creates the initial workspace API key.
7. The application switches into the new workspace and guides the user toward projects.

Guided quick-start actions include creating a project, creating or cloning a release, inviting members, integrating a model, configuring reviewer or custom-model projects, trying batch/crop auto-annotation or Magic Touch, and opening project/member statistics.

### Workspace switching and settings

The workspace area includes:

* workspace list and switcher;
* general settings for name, purpose, and logo;
* account security and 2FA;
* billing and pricing portal;
* usage and quota visibility;
* members and member statistics;
* Roles & Permissions editor;
* API keys;
* cloud storage connections;
* user profile.

Usage can report datasource, image, video, medical, token, audio-duration, AI-inference, and member consumption. The interface warns when a downgraded plan would be exceeded.

Workspace destruction is intentionally different from leaving a workspace. It is Owner-only, requires the exact workspace name, and requires a second factor when the Owner has 2FA.

### Members

Member management supports search, filtering, invitations, role changes, member actions, analytics, and Active, Pending, Disabled, and Rejected states. Pending invitations can be resent.

### Built-in and custom roles

Built-in roles include:

* Owner;
* Manager;
* Member;
* Annotator;
* Reviewer.

Administrators can also create custom roles for workspace-specific access patterns.

Roles can be configured to permit assignment as an Annotator or Reviewer.

Workspace role and project position are different:

* **Workspace role** controls tenant-wide capabilities.
* **Project position** determines eligibility for annotator or reviewer workflow stages.

Owner, Manager, and custom roles use the administrative branch by default. Member, Annotator, and Reviewer are assignment-scoped and see only the stage queues and work items for which they are eligible.

### Permission groups

Granular permissions include:

**Workspace**

* manage workspace settings;
* manage billing;
* manage API keys;
* manage cloud storage;
* manage members.

**Projects and schemas**

* manage projects;
* manage ontologies;
* assign project members;
* manage releases;
* view ontology;
* view instructions;
* manage instructions.

**Annotation and review**

* view labeling interface;
* create labels;
* comment;
* view statistics.

**Models and data**

* manage data;
* manage AI models;
* manage workflows;
* manage augmentation.

### Governance pattern

Separate high-impact administration from production work. An annotator rarely needs permission to manage API keys, cloud storage, releases, or ontologies. A reviewer should be able to make review decisions without necessarily changing the schema. External contributors should receive a minimal custom role and access only to the projects they need.

### Use this in production

* Track active projects, member growth, source volume, dataset versions, queue backlog, invalid and failed work, model processing, and releases.
* Define thresholds and owners for capacity, failure, and subscription or quota signals.
* Review privileged roles, unused custom roles, service identities, cloud connections, and stale projects on a schedule.
* Archive or retire resources through documented lifecycle paths rather than deleting operational history.
* Use stable IDs and periodic reports so trends remain comparable across display-name changes.