Unify Logo Footer.svg
Unify Applications
Logo
Managing Template Components

Managing Template Components

Logo

9 mins READ

Overview

As a workspace accumulates template components, the library needs active management to remain useful. Without curation, builders face a growing list of components with unclear purposes, outdated designs, and no way to know which apps depend on which template. This guide covers the full lifecycle of a template component after it is created: how to organise and find it, how versioning works, how to push updates to consumers, how to signal that a template is no longer recommended, and how to track where a template is used.

For creating a new template component from scratch, see Creating a Template Component.

Accessing the Template Component Library

Template components are managed from the workspace-level library panel, which is accessible from two places:

  • Left sidebar → Template Components icon — from inside any Application Builder, the template component icon in the left sidebar opens the library panel. This is the view used during active building — you browse, search, and insert templates from here.

  • Workspace Settings → Template Components — the workspace-level management view, which shows all templates with full metadata, version history, usage tracking, and administrative actions. This is where you publish, deprecate, and manage permissions.

The Builder sidebar panel shows a read-optimised view for browsing and inserting. The workspace settings view shows an admin-optimised view for governance and lifecycle management.

Organising the Library

A well-organised template library reduces the time builders spend searching and increases the likelihood they discover and reuse existing patterns.

Folders

Templates can be grouped into folders by domain or function. Common organisational schemes:

  • By component type — Forms, Tables, Cards, Navigation, Dashboards, Charts.

  • By business domain — CRM, Finance, Operations, HR, Customer Support.

  • By app type — Web components, Mobile components, Copilot components.

To create a folder, go to Workspace Settings → Template Components → New Folder. Folders can be nested up to two levels deep. Drag templates between folders to reorganise the library.

Tags

Tags complement folders by enabling cross-cutting classification. A "Job Completion Form" template might live in the Forms folder but also carry tags: mobile, field-service, data-entry. Builders can filter the library by tag to find all mobile-optimised templates regardless of folder.

Add tags from the template's detail panel in Workspace Settings → Template Components → [template name] → Tags.

Search and Filter

The Builder sidebar library panel supports:

  • Name search — type in the search bar to find templates by name substring.

  • Tag filter — click a tag chip to filter to templates with that tag.

  • Usage count sort — sort templates by how many apps use them, surfacing the most adopted patterns at the top. Access this sort option in the admin view.

  • Deprecation filter — hide deprecated templates from the picker (the default). Toggle to include deprecated templates when you need to audit usage.

Versioning

Template components are versioned. Each time a template is published, a new version number is created. Apps that consume the template record the version they last updated to, enabling the platform to show update notifications when new versions are available.

Version Numbers

Version numbers follow a simple incrementing integer scheme: v1, v2, v3, and so on. Each publish of a template creates the next integer version. There is no concept of major/minor/patch versioning — all published versions are treated as sequential updates.

Update Badges

When a template used by an app is updated to a newer version, the app's template component insertion shows an update badge — a small indicator in the Builder sidebar that the template has a newer version available. Builders can:

  • Update to latest — replace the current template insertion with the latest published version. This is a destructive operation for any manual edits made to the template instance after insertion — see the warning below.

  • Pin to current version — explicitly mark the insertion as intentionally staying on the current version. No update badge is shown until a new version is released after the pin date.

  • Dismiss the notification — hide the badge without updating or pinning. The badge returns on the next visit.

Warning: Updating replaces local edits. When you insert a template into a page, the resulting blocks are fully editable. If you update the template instance to a newer version, those local edits are replaced by the new version's content. The update is not a merge — it is a replacement. Save a copy of your customised blocks to a different location before updating if you need to preserve local changes.

Viewing Version History

From Workspace Settings → Template Components → [template name] → Versions, you can browse all published versions with timestamps and the user who published each one. You can preview any historical version's block structure, but you cannot roll back the template to a previous version from the admin UI — to "roll back", create a new version based on the old structure.

Publishing a Template

When you create or edit a template component, the changes exist as an unpublished working state until you explicitly publish. Publishing creates a new version that consumers of the template can update to.

  1. Edit the template: Open the template in the Template Builder. Make your structural changes — add, remove, or modify blocks, inputs, slots, and overrides.

  2. Preview the changes: Use the Template Builder preview to verify the template renders correctly. Check it with different sample input values if the template accepts inputs.

  3. Click Publish: Click the Publish button in the Template Builder top bar. You are prompted to enter an optional change note describing what changed in this version. Change notes appear in the version history and in the update notification shown to builders consuming the template.

  4. Monitor update adoption: After publishing, apps using the template show update badges to their builders. You can track how many apps have updated versus how many are still on the old version from the template's Usage tab.

Note: Publishing a template does not automatically update apps. Each app that uses the template must opt in to the new version. Builders see an update notification but must actively choose to update. This prevents unintended breaking changes from propagating to all apps automatically.

Deprecating a Template

Deprecation signals that a template is no longer the recommended choice. Deprecated templates remain usable but are excluded from the default library view and show a warning on existing usages.

How to Deprecate

From Workspace Settings → Template Components → [template name] → click the Deprecate action in the template's action menu. You can optionally provide:

  • Deprecation reason — a message shown to builders who encounter the deprecated template. Example: "Replaced by the Enhanced Data Card template which supports dark mode and configurable column widths."

  • Replacement template — link to the recommended replacement. The deprecation warning shown in the Builder will include a "Go to replacement" link.

Effects of Deprecation

ContextEffect
Library panel (Builder sidebar)Deprecated templates are hidden from the default view. Builders must toggle "Show deprecated" to see them.
New insertionsBlocked — builders cannot insert a deprecated template into a new page. They must use the replacement instead.
Existing usagesPages that already use the deprecated template continue to function. A deprecation warning badge appears on the template instance in the Builder, with a link to the deprecation reason and recommended replacement.
Update notificationsSuppressed — no further update notifications are shown for deprecated templates even if new versions are published.

Deprecation can be reversed by clicking Un-deprecate from the template's action menu. The template returns to active status and appears in the library picker again.

Usage Tracking

Understanding where a template is used is critical before making structural changes and before deprecating. The usage tracking feature shows every app and page that currently references a template.

Viewing Usage

From Workspace Settings → Template Components → [template name] → click the Used In tab. The tab shows:

  • A list of all apps that have at least one insertion of this template.

  • Within each app, the specific pages where the template is used.

  • The version currently in use in each app (useful for identifying stale adoptions).

  • A direct link to open the relevant page in the Application Builder.

Usage counts are also visible in the library's main list view — the column "Used in" shows the total number of apps using each template, enabling you to sort by adoption to prioritise which templates to maintain most actively.

Impact Analysis Before Changes

Before publishing a version that includes breaking structural changes (for example, renaming an input, removing a slot, or changing a block's hierarchy), review the Usage tab to understand how many apps the change affects. Consider:

  • Apps on the latest version will update when their builders accept the update notification. Structural changes may require adjustments in those apps.

  • Apps pinned to a specific version are not affected by new versions until they unpin.

  • High-usage templates should have changes communicated to the team before publishing to avoid builders encountering unexpected update notifications.

Permissions

Access to template component management is controlled in Governance → Permissions → Template Components. The following permission levels are available:

PermissionGrants Access To
ViewBrowse the library, insert templates into pages. Cannot create, edit, or publish templates.
CreateCreate new templates and save drafts. Cannot publish to the shared library.
PublishPublish new versions to the shared library, making updates available to all apps. Includes Create access.
DeprecateMark templates as deprecated and set replacement references. Includes Publish access.
ManageFull control: create folders, manage tags, permanently delete templates, manage usage tracking. Includes all permissions above.

Permissions are assigned per user or team group. Typically, a small team of platform engineers or design system owners hold Publish and Deprecate access, while all builders have View access.

Import and Export

Templates can be exported as JSON files for sharing across workspaces — for example, sharing a design system's templates with a partner team or migrating templates between workspace environments.

Export a Template

From Workspace Settings → Template Components → [template name] → click Export as JSON. The exported file contains the template's block tree, inputs, slots, overrides, metadata (name, description, tags), and the latest published version's content. Version history is not included in exports.

Import a Template

From Workspace Settings → Template Components → click Import Template and upload a previously exported JSON file. The imported template is added to the library as an unpublished draft. Review and edit before publishing it to the workspace.

Note: Imported templates are not automatically connected to the original source. An imported template is an independent copy in the destination workspace. Changes to the original template in the source workspace are not propagated to the import. Re-export and re-import to sync changes manually.

  • Template Components Overview — what template components are and how they differ from modules.

  • Creating a Template Component — step-by-step guide to building a new template from scratch.

  • Inputs, Slots & Overrides — making templates configurable so they work in multiple contexts.

  • Permissions — configuring who can create, publish, and manage templates.