> 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/workspace-settings.md).

# Workspace settings

Workspace settings influence people and resources across projects. Treat changes to ownership, permissions, storage, models, integrations, and subscription context as shared configuration changes.

### Before you make the change

* Identify affected projects, integrations, service identities, and owners.
* Record the current state and reason for change.
* Define a test and rollback or containment path.

### Understand the product behavior

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.

### Change shared configuration safely

{% stepper %}
{% step %}

#### 1. Open the correct workspace

Confirm workspace ID, owner, environment, and current settings.
{% endstep %}

{% step %}

#### 2. Identify the control

Determine whether the change affects identity, storage, models, data, projects, releases, or subscription behavior.
{% endstep %}

{% step %}

#### 3. Review dependencies

List the people, jobs, projects, and source systems that rely on the current setting.
{% endstep %}

{% step %}

#### 4. Apply the smallest change

Use the minimum scope needed to achieve the intended result.
{% endstep %}

{% step %}

#### 5. Test effective behavior

Verify expected access and resource operations with representative users or workloads.
{% endstep %}

{% step %}

#### 6. Record and monitor

Capture owner, reason, affected scope, result, and next review trigger.
{% endstep %}
{% endstepper %}

### Decisions that affect production

| Decision  | Production guidance                                                                  |
| --------- | ------------------------------------------------------------------------------------ |
| Scope     | Prefer project-level configuration when the requirement is not truly workspace-wide. |
| Ownership | Every shared integration or setting needs an accountable role.                       |
| Timing    | Schedule high-impact changes around active tasks and automated workloads.            |
| Recovery  | Know how to restore service without reintroducing excessive access.                  |

### Continue the operating flow

* Review membership and roles.
* Re-test cloud and model integrations when shared settings change.
* Update production-readiness evidence for material changes.