Workspace templates

Overview

Workspace templates (WB.9) let a platform admin freeze a known-good workspace configuration into a reusable blueprint and stamp it out as many times as needed. The blueprint is a WorkspaceTemplate model with a single snapshot JSONField that holds every cloneable artifact — settings, approval policies, playbooks, custom fields, role definitions, navigation overrides — in a structured, versioned shape. Two actions drive the feature: Create template from current workspace captures the blueprint, Create workspace from template stamps a new one.

The page lives at /ws/{slug}/platform/templates. The list shows every template visible to you, with a chip indicating is_public (shared org-wide) or is_private (only visible inside the source workspace). The detail view shows the structured snapshot tree so you can diff two templates before stamping.

Why it exists

Multi-tenant orgs end up with workspaces that drift apart. Team A configures a SOC2-aligned approval policy with three stages and a CAB gate, Team B builds the same intent in a slightly different shape, and six months later the compliance auditor finds inconsistent change records across the org. Templates remove the drift: a platform admin freezes Team A's setup as soc2-aligned-engineering, and every new engineering workspace stamps that template instead of starting from defaults. The cost of doing things consistently drops to one click.

Templates also help spin-up speed. A new team going from "we got approved for a Vigilo workspace" to "we are operating in it" used to take a day of clicking through settings. With a template it's the time it takes to type a workspace name.

Key concepts

• WorkspaceTemplate model — Fields: name, description, snapshot (JSONField), is_public (bool), created_by, created_at. The (workspace, name) pair is unique. Public templates are visible across the whole installation; private templates only show up in the workspace they were created in.
• snapshot JSONField — A structured dict with top-level keys settings, approval_policies, playbooks, custom_fields, roles, navigation, webhook_signing_keys (key metadata only, never secrets), incident_severity_levels, slo_objectives, cab_meeting_template. Each key holds an array of records that the stamp-out action will recreate.
• Create template from current workspace — A workspace owner/admin runs this from Settings → Templates → New template from workspace. The action introspects the live workspace, serialises every cloneable record into snapshot, and writes the row. Secrets (encrypted tokens, passwords, signing-key secrets) are NEVER included — only the structural metadata.
• Create workspace from template — A platform admin (or anyone with workspace.create permission) opens Platform → Templates → New workspace and picks a template. They name the new workspace, choose a slug, and confirm. The action creates the Workspace row, then iterates the snapshot tree creating each child record under the new workspace_id.
• is_public flag — Marks a template as available to every workspace in the installation. Useful for org-blessed blueprints like "compliance-baseline" or "engineering-team-standard". Private templates stay scoped to their creating workspace.

What gets cloned, what does not

Cloned:

• Workspace settings dict (timezone, business hours, branding flags, default change SLA hours, enforce_sod, idle_timeout_minutes, mfa_required_for_actions list, ip_allowlist)
• All ApprovalPolicy rows with their conditions and stages
• All Playbook rows with their triggers and steps
• All CustomField definitions per entity type
• All CustomRole rows with their permission grants
• Navigation overrides per role
• All IncidentSeverityLevel and SLOObjective definitions
• Webhook signing key labels (without secrets — new keys must be rotated post-stamp)
• CAB meeting cadence configuration

Not cloned:

• Members (the new workspace starts with just the creator)
• Hosts, certificates, incidents, changes — any operational data
• Encrypted secrets — Slack tokens, Jira tokens, SMTP passwords, webhook secrets, signing-key material
• Audit log
• Integration connections — you must reconnect Slack/Jira/PagerDuty per workspace
• Approval/incident history

Common workflows

1. Freeze a known-good workspace as a public template

1. From the source workspace, open Settings → Templates.
2. Click New template from this workspace.
3. Give it a clear name like engineering-soc2-baseline and a description that explains when to use it.
4. Tick Make public so other workspaces can see it.
5. Save. The snapshot is captured immediately — later changes to the source workspace do NOT update the template.

2. Stamp out a new workspace from a template

1. Open Platform → Templates (or Settings → Templates if you're not a platform admin but have workspace.create).
2. Find the template in the list. Public templates have a globe icon.
3. Click New workspace from template.
4. Enter the new workspace name (e.g. "Platform Engineering"), slug (platform-eng), and region.
5. Click Create. The action creates the workspace, runs the snapshot replay, and redirects you into the new workspace's onboarding flow.
6. Invite members and reconnect integrations — those steps are intentionally not cloned.

3. Diff two templates before adopting

1. Open Platform → Templates.
2. Tick two templates and click Compare.
3. The dialog shows a side-by-side JSON diff of the two snapshots. Useful for picking between soc2-strict and soc2-relaxed.

4. Update a template

Templates are immutable once created. To "update" a template, stamp out a workspace from it, change what you need, and create a new template from that workspace with a new version suffix (e.g. engineering-baseline-v2). Mark the old one inactive (set is_public=False) so people stop using it.

Permissions

Troubleshooting

The stamp-out fails halfway through. The action is wrapped in a transaction, so a partial workspace will roll back — you will not see an orphaned workspace. Check the Celery logs for the underlying error (most common: a CustomField definition that references a custom type the new workspace's plugin registry does not have).

My approval policy is in the template but did not appear in the new workspace. Policies depend on roles. If your template references a CustomRole that the stamp-out failed to create (because of a missing permission key), the policy is silently skipped with a warning. Check the stamp-out audit entry for the warning list.

The "create from template" button is greyed out. You do not hold either platform_admin or workspace.create. Ask a platform admin to grant the permission or to do the stamp-out for you.

My template is missing the Slack integration. That is by design — secrets do not clone. Reconnect Slack from the new workspace's Integrations page after stamp-out.

Related articles

• Executive dashboard — see template adoption rates per workspace.
• Cost attribution — templates do not affect cost, but uniform workspaces are easier to chargeback.