Extensions (workspace)

Extensions is the single place in the agentic app where you turn on the content your organization has installed, for your workspace environment. It replaces the former separate Templates and Process Flows surfaces, and was previously called "Extensions" — a name that promised a store, when the page only ever listed what your organization already had.

Opening Extensions

Click Extensions in the agentic sidebar. The page lists everything available to your organization in a single table — one row per item. A free-text search plus a content-type filter (All / Process flows / Workflows / MCP servers) narrow the list:

• Process flows — structured, repeatable process flows (stages, tasks, personas). Authored via the SDK and shipped as extensions.
• Workflows — executable block-graphs. Deploy them into the active environment to run as standalone automations or as the automation behind a process flow task.

All Turn on and Deploy actions target the active workspace environment.

Browsing content

Each row shows:

Process-flow rows without an On badge are available but not yet turned on in the current environment.

When several versions of the same extension are installed, Extensions lists each template or workflow once, from the latest installed version — older versions never appear as duplicate rows. Managing installed versions (updating, pinning, retiring) happens on Settings → Platform → Extensions → Installed, in the extension's Version & security tab.

Updating an ontology extension to a newer version

Enabling an ontology extension from Analytics → Marketplace installs a workspace-environment-scoped copy of its ontology and bindings. That action always targets the active environment — the copy shown by the Ontology Designer and graph (labelled "… (Workspace · <env>)"). Uploading a newer extension version via Settings → Platform → Extensions → Sources → Upload an extension (one-off) updates the org catalog, but it does not silently change your workspace copy.

An organization administrator has a separate operation in Settings → Platform → Extensions. Publishing, installing, updating, or repairing ontology content from that organization-wide surface enumerates every existing workspace environment and applies the extension to each one. It is not a write to a single organization-level ontology. The action reports success only when all environments succeed; a partial result is safe to retry because already-applied targets are idempotent.

When a newer catalog version is available, you'll see an Update affordance in two places:

• the Ontology Designer (/ontology) shows a "Newer version available → Update to v<x>" banner above the workbench whenever the selected ontology is behind its extension's catalog version;
• the Analytics → Marketplace row shows an Update to v<x> button next to the Installed badge.

The Ontology Designer and Analytics Marketplace actions update only the active environment. The organization-wide Settings action updates every existing environment. Either path re-applies the extension's bindings (identity columns, column map, transforms, binding context, source) in place — no need to unbind or re-pick anything. Updates are always an explicit click, so a workspace ontology you've customised is never overwritten without your action.

The organization Settings → Platform → Extensions view reports ontology state only when every expected environment agrees on extension version, catalog/source provenance, and normalized manifest. If one environment is missing the extension or has divergent content, the ontology state is unavailable/inconsistent rather than being inferred from one arbitrary environment. Environment-local revision IDs and timestamps may differ without making extension state divergent.

Turning on a Process Flow

Turning on a Process Flow opts it into the active workspace environment. Once it is on, the template appears in Process Flows and can be instantiated by any workspace member.

Turning off a Process Flow

Click Turn off on a template row that is on to withdraw it from the active environment. This hides it from the Process Flows creation flow but does not affect any running Process Flows — they hold a frozen snapshot of the template taken at instantiation time and continue to run unchanged.

Deploying a Workflow

Deploying a workflow materializes it into the active workspace environment. Deployed workflows become available in the workflow editor and as workflowId targets for process flow action templates.

Deployed workflows carry an Extensions badge in the workflow selector — hover it to see the source extension and template. They can be opened, edited, and renamed like any workflow, but they cannot be deleted from the selector or the API: their lifecycle belongs to the extension that ships them, and re-deploying the extension version overwrites them in place.

Process Flows

After adding a Process Flow, workspace members can start a new run from Process Flows in the sidebar. Each run is a Process Flow — a live, independent instance that carries a frozen snapshot of the template taken at instantiation time. Subsequent changes to the template (via a new extension version) do not affect running flows.

See Process Flows for how to author a Process Flow via the SDK.

Tracing a Process Flow's origin

Every workspace member who can open a Process Flow can select Debug in its header. The right-side panel shows the source extension and template, who created the instance, and—when retained execution data proves the link—the triggering workflow, trigger type, execution status, timestamps, and a link to replay the execution in the workflow editor.

The panel includes only bounded, secret-redacted error summaries; it does not expose webhook payloads, headers, or workflow inputs and outputs. If the creating execution is no longer retained, it reports the origin as unavailable instead of guessing from nearby timestamps.

Deleting a Process Flow

Deleting a Process Flow (from the card menu on the Process Flows page, or from the flow's header) is permanent and cannot be undone. To prevent accidents, you must type the flow's name to confirm. The deletion removes:

• The flow itself, with all its stages, tasks, actions, meetings, and extractions.
• The workspace knowledge base that was auto-created for the flow at instantiation time, including all its pages and uploaded documents.

Roles summary

Where content comes from

All Extensions content comes from the org extension catalog — the set of extensions an org admin has installed via Settings → Platform → Extensions. There is no in-app content creation. To author new Process Flows or Workflows, use the Authoring SDK and publish an extension.