# Workspace tenant variables: one value per customer, for every project

Source: https://www.jawsdeploy.net/changelog/workspace-tenant-variables

Keep each customer's shared values in one place, and see exactly which values a deployment used.

## Workspace tenant variables

Some customer values belong to more than one project: a site and its API often share a port or a secret. Until now each project needed its own tenant variable, so the same value was kept in several places. A **workspace tenant variable** is defined once for the workspace, and each tenant fills in its value once. Every project that uses the variable gets that value.

### Set them up

Add them under **Setup** → **Tenant variables**, with the same options as a project's: type, required, default and description. A project gets one only after you pick it: on the project's **Tenant variables** tab, click **Use workspace variables**. **Stop using** removes it from that project, and the tenants keep their values, so other projects aren't affected.

Scripts and step properties read them like any other variable, `#{VAR.Port}`. A variable can't be deleted while a project uses it; the message lists those projects.

### Fill in the values

The tenant page has a new **Workspace variables** card with each variable the tenant's projects use, once, for all environments or per environment. Values can also be edited on a project's **Tenants** tab, where the row says "Workspace variable - shared by 2 projects", because the change applies to every project that uses it.

### Deploying

A required value that is missing stops the tenant's deployment like any other tenant variable, but only in projects that use the variable. As with all tenant values, they are read when a deployment is created, so a new customer doesn't need a new release.

### Move a variable you already have

On a project's **Tenant variables** tab, **Move to workspace** turns a project's tenant variable into a workspace one, with its settings and the tenants' values. If the workspace already has a tenant variable with that name and type, the project uses that one instead, and a tenant's value is added only where it has none there yet. If a tenant has two different values, Jaws stops and lists the tenant rather than overwriting anything.

### Turning customer environments into tenants

[Copy to a new workspace with tenants](https://www.jawsdeploy.net/changelog/tenants) now turns a workspace variable with per-customer values into one workspace tenant variable, used by the projects that use tenants and imported it, rather than a separate tenant variable in each project. The preview shows this on each variable before anything is created. The copy also brings the tenant variables the workspace already has.

### REST API and MCP

New endpoints: `/api/workspace/tenant-variable-templates` and `/api/workspace/tenant-variable-template` to manage them, and `/api/project/workspace-tenant-variables` to see and pick the ones a project uses. `/api/tenant/variables` without a `projectId` reads and sets a tenant's workspace values.

AI assistants connected through [MCP](https://www.jawsdeploy.net/features/mcp) get `list_workspace_tenant_variables`, `create_workspace_tenant_variable`, `update_workspace_tenant_variable`, `delete_workspace_tenant_variable`, `use_workspace_tenant_variable` and `stop_using_workspace_tenant_variable`. `get_tenant_variables` and `set_tenant_variables` work without a project for workspace values. Secret values still can't be set through MCP.

## See what a deployment used

The deployment page has a new **Tenant values** section: each value the deployment copied from the tenant, and whether it came from all environments, one environment or a default. Workspace tenant variables are marked **workspace**, and secrets stay hidden. The same list is available as `tenantValues` from `GET /api/deployment` and from MCP's `read_deployment_log`.

## See a release's variables

The release page has a new **Variables** section showing the variables stored with that release, read-only. It's shown to people who can view the project's details.

## Changed

### Clearer variable overrides

When a project variable has the same name as a workspace variable the project imports, the project's value wins. The **Variables** tab now marks both, so you can see which one is used.

### Renaming a workspace variable

Renaming a workspace variable is now refused if a project that imports it already has a tenant variable with the new name.