Skip to main content
Version: 0.9.18

Manage shared team variables and secrets

Use team variables for configuration shared by multiple flows, such as an API base URL or a provider credential. These values belong to the team; they are not per-conversation scratch variables. A change can affect several applications, so identify the consumers before editing.

Availability: open Settings → Variables in the intended team. Team Admins manage ordinary variables; platform administrators also manage platform-controlled entries. Platform Superviewers remain read-only. See Access and teams before requesting a role change.

Who can see and change entries​

The Variables tab depends on team configuration access and the plan's custom-LLM-key allowance; platform-wide readers retain inspection access. Variable writes also enforce the applicable plan policy. Subscription management being disabled changes backend enforcement, but is not a reason to assume every hidden UI control should appear. Ask the administrator to distinguish entitlement, role and missing team selection.

A Super-Admin-managed entry is locked for ordinary team administration. Its presence does not grant permission to replace its value. When the Variables tab is available, managed entries can appear with locked actions; they are not universally hidden from the list.

Choose the right storage type​

Field/typeMeaning and handling
KeyUnique within the team; referenced by consumers. Choose a stable name before creating it.
PLAIN_TEXTStored as an ordinary database value and visible to readers. Use for non-sensitive configuration, never a password or API key.
SECRETValue is stored in the team's secret storage. Read responses mask the value and show whether one was found.
DescriptionExplain purpose and owner without copying the secret.
Super-Admin-managedPlatform-controlled management lock, not a separate encryption mechanism. Only the platform administrator can change it.

A masked value is not proof that the external service accepts it. A missing-value indication can also reflect a storage lookup problem. The key, description and tool source are not secret storage.

Create and verify a shared value​

  1. Confirm the team and list of flows/tools that will use the key. For SECRET, first connect team secret storage.
  2. Choose Create, supply the key, type and description. For PLAIN_TEXT, supply its value and save.
  3. For SECRET, save the variable metadata, then use Set Secret on that row to enter, confirm and save the actual credential. These are separate operations: creating the row does not populate the secret value.
  4. Confirm the row and its value-presence status without trying to reveal the secret. Resolve storage errors before testing a consumer.
  5. Reference the approved key in the consumer, for example {{team.serviceUrl}} or {{team.serviceToken}}. Use only a field that supports team-variable substitution; creating a key does not attach it to a provider or tool automatically.
  6. Check publication readiness and run a controlled new interaction. Verify the expected external effect, for example a successful provider connection or HTTP response. Use Provider and channel configuration for provider credentials and Team tools for HTTP integrations.

Secret values are resolved into runtime configuration where required. UI masking does not mean a credential is safe to place in a prompt, returned tool result, browser action or log. Keep credentials in the server-side authentication field that needs them and share only redacted diagnostics.

Activation, changes and recovery​

Variable creation, value/key updates, secret setting and deletion attempt to synchronize referencing team flows to the runtime. Those synchronization errors are caught and logged separately; a successful variable save does not establish that every consumer received the new value. Verify a new controlled interaction and involve the operator if saved and effective values appear inconsistent. No guarantee is made that an already-running conversation adopts a rotation immediately.

Runtime preparation combines ordinary values with the team's consolidated secret payload; a same-named payload entry can take precedence. Avoid duplicate/stale names across the two stores. If the effective value differs from the expected PLAIN_TEXT row, ask the storage operator to inspect this boundary without exposing the payload.

Treat a key rename as a migration: update references and verify the new value. Renaming SECRET metadata does not itself rename its entry inside the external secret payload. Prefer creating and populating the replacement key, migrating consumers, verifying them, then removing the old key deliberately.

Use Set Secret to rotate a value; it overwrites the stored value for that key. Coordinate provider revocation with consumer verification. The masked UI cannot recover the previous value for you.

Deletion is not a rollback. It can break references, and a SECRET row can be deleted even when external-secret cleanup fails. Have the operator verify cleanup rather than treating absence from the list as proof that the AWS value was removed.

Platform-managed defaults​

For the source keys and their values, use Platform settings and secrets. Team variables remain separate records; changing a platform value is not the same operation as rotating an existing team value.

The platform's team-default provisioning supplies managed openaiDefaultKey and azureDefaultKey rows for every plan in this version. Values are copied only when the corresponding registered platform secret has a value. A row or template reference alone therefore does not prove usable credentials.

When API access is enabled, provisioning also attempts to establish the system browser-session key; this is separate from the provider keys and does not prove WebRTC infrastructure is ready. Browser integration still has its own access and runtime prerequisites.

Re-running defaults is not a preserve-overrides operation. When a platform value exists, provisioning writes it into the corresponding managed team secret, including an existing one. Before a backfill or re-provisioning operation, the platform administrator must check whether a team-specific override is intentionally in use. Changing a platform secret is not itself evidence that all existing teams have been updated.

For an empty or rejected managed provider key, ask the platform administrator to check the registered platform secret, actual team value and runtime synchronization. Do not delete the managed row or run a fleet-wide backfill merely to retry one failed call.

For the Team tab’s AWS storage pointers and suggestion helpers, use Connect team secret storage.