Workspace Templates

Publish a workspace as a starting point others can clone from the Builder

A workspace template is a workspace that appears as a “Start from template” tile when a user creates a new workspace in Builder. Picking it duplicates the source workspace (automations, imports, pages, configuration) into a fresh workspace owned by the user.

Templates are declared at the organization level via the Menu Editor, so publishing one is a governance task, while the source workspace itself is built and maintained through Builder’s full-code door. In other words, the same unified foundation lets governance publish a reusable starting point that builders then fork and adapt. See Builder for the source-workspace side.

Use templates to:

• Standardize a starting point for new use cases (e.g. “Custom RAG”, “Webhook gateway”, “OAuth-enabled connector”)
• Share a polished demo with colleagues without giving them write access to your workspace
• Bootstrap reference architectures your team can fork and adapt

How templating works

Templates are declared in AI Governance as Template Features on a navigation menu item. The Builder reads the platform navigation to populate its “Create new workspace” screen; every Template Feature shows up as a tile.

When the user picks a template, the Builder calls POST /workspaces/<templateId>/versions/current/duplicate. The duplicate inherits all content but gets a new id, a - Copie suffix in its name (which the user can rename in the next step), and is owned by the cloning user.

Step 1: Polish your source workspace

Before publishing, treat your source as a product:

• Name & description: both are surfaced to the user during template selection. Be concrete: RAG agent over a public website beats My template.

• Photo / icon: set one in workspace settings. It’s the visual users see in the gallery.

• Configuration schema: if your template needs the cloning user to provide values (an API base URL, a brand name, etc.), declare them in config.schema. The Builder will render a form when they instantiate the template.

• Secrets schema: for sensitive values (API keys), declare them in secrets.schema. The user is prompted at instantiation and the values land in their workspace’s Secrets.

• No personal data: clear out test users, real tokens, hard-coded customer ids. Anything that would embarrass you in someone else’s workspace shouldn’t be in the template.

• Mark it as a template with the toggle in Builder (workspace settings). This provisions two things together: the template label and two open-read DSUL security rules (read on workspaces and pages). It’s those security rules — not the label — that authorize users who don’t otherwise have access to the source to duplicate it. Without them, the duplicate call is denied for anyone but the workspace’s own collaborators, and the “Start from template” tile fails silently.

Note the workspace id (visible in the URL when you open the workspace, e.g. kFoNvfX); you’ll need it in step 2.

The public-duplication grant is the pair of open-read security rules, not the label itself: they grant read on the workspace and its pages to any authenticated user, which is what lets a non-collaborator clone the source. The resulting workspace is still owned by the cloning user, with default security — the source’s collaborators and custom roles are not inherited, and the open-read rules themselves are stripped from the copy (they carry a REMOVE_ON_DUPLICATE marker). Turn off Mark as template to remove both the label and the rules, immediately stopping new duplications without touching the source content.

Step 2: Declare it as a Template Feature in AI Governance

Templates are managed at the organization level via the Menu Editor. Anyone with admin access to the org navigation can publish a template.

1. Open the Govern product (AI Governance) from the sidebar.
2. Go to Menu Editor.
3. Open (or create) a menu item where the template should be discoverable. Templates are attached as features of menu items; typically you’d attach them under a “Builder” or “Workspaces” entry.
4. Click Add Feature → Template Feature.
5. Fill in the four fields:

Field	Description
Slug	Short identifier used in URLs and translations (e.g. custom-rag-template). Lowercase, hyphens.
Template ID	The workspace id or slug of the source template (the one from step 1).
Label	The display name shown on the tile in Builder.
Permissions	Optional. Restricts visibility to roles holding any of the listed permissions. Leave empty to make the template visible to everyone with platform access.

6. Save Changes. The Template ID is validated on save: the feature is rejected unless the id references a workspace that exists, is readable by you, and is declared as a template (carries the template label). This avoids publishing a tile that would fail at instantiation — or one that only works for you because you can read a workspace others can’t.

Equivalent YAML if you edit the navigation via the API:

menu:
  - type: item
    label: Builder
    icon: hammer
    href: /builder
    features:
      - type: template
        slug: custom-rag-template
        templateId: kFoNvfX
        label: Custom RAG Template
        permissions:
          - builder:workspaces:create

Adding the Template Feature is reflected immediately in Builder’s “Create new workspace” screen, with no rebuild or cache flush.

Step 3: (Optional) Add a configuration form

If your template needs inputs at instantiation, declare them in the source workspace’s config.schema. The Builder renders a form, and the values become accessible inside the cloned workspace as {{config.<field>}}.

# In the source workspace (config tab)
config:
  schema:
    sourceUrl:
      type: string
      title: Website to crawl
      description: The starting URL the RAG agent will index
      required: true
    brand:
      type: string
      title: Brand name
      description: Used in the agent's greeting and prompts
secrets:
  schema:
    OPENAI_API_KEY:
      type: string
      title: OpenAI API Key
      description: Required to call the embedding model
      required: true
      secret: true

After filling the form, the user lands in a fully wired workspace where every {{config.sourceUrl}} reference resolves to their value.

Step 4: Verify the template

1. Open Builder → click New workspace.
2. The first step lets users pick a starting point. Your template should appear alongside From scratch and Import ZIP.
3. Click your template tile, fill the configuration form (if any), and complete the wizard.
4. The new workspace opens in your account; verify it has the expected automations, imports, and config.

Visibility & permissions. Template Features inherit the standard menu-item permission model: if you set permissions, the tile is visible only to users holding any of the listed permissions. Leave it empty to expose the template to everyone with access to the parent menu item. See Permission-Based Visibility for the full rules.

Maintaining a template

A template is just a workspace, so:

• Update it like any other workspace; changes are picked up by future “Create new workspace” clicks (existing copies are not modified).
• Use versioning to mark stable releases. Builder always duplicates the current version, so pinning your changes through current lets you keep iterating on a separate branch.
• Retire a template by removing the corresponding Template Feature from the Menu Editor. The source workspace stays intact.

Templates vs publishing as an app

Don’t confuse a template with publishing a workspace as a platform app:

	Workspace template	Published app
Purpose	Starting point users clone and modify	Live application users open and use
Where it’s declared	Govern → Menu Editor → Template Feature	”Add to Platform” modal (bundles + route)
What user gets	A new workspace in their account	A new entry in the platform navigation
Where users find it	”Create new workspace” → tiles	Sidebar / app launcher

You can do both: a template that users clone for customization and a published app that users open as-is.

Related

Workspaces

Workspace anatomy: configuration, secrets, sharing.

Menu Editor

Where Template Features live, plus the wider menu/navigation model.

Versioning

Pin a template to a stable version while you iterate.

Identity & Access

Permissions model used by the Menu Editor’s visibility filters.