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 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 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.

Highlights

  • Workspace tenant variables - define a variable once, pick the projects that use it, and each tenant sets one shared value.
  • Move to workspace - turn a project's tenant variable into a workspace one, with its values.
  • Workspace variables card on the tenant page, and "shared by" on a project's Tenants tab.
  • Converting to tenants - a workspace variable with per-customer values becomes one workspace tenant variable.
  • Tenant values on the deployment page, in the REST API and in MCP.
  • Variables on the release page.
  • Changed - project variables that override a workspace variable are marked, and renaming a workspace variable checks for tenant variables with that name.