> For the complete documentation index, see [llms.txt](https://docs.guardianservice.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.guardianservice.app/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-templates.md).

# Schema Templates

Reusable schema standards that a policy can apply, with restrictions that hold.

A Schema Template is a standalone entity that owns a set of schemas and the rules governing how much of them a policy author may change. A policy applies a template, receives its own copies of the template schemas, and keeps the template's restrictions.

Schema Templates appear under **Schema Templates** in the navigation, which is visible to users whose role carries the template read permission.

## The problem it solves

Policy authors often need to reuse the same schema standard across multiple policies. Without Schema Templates, each policy owns and maintains its schemas independently. That makes it hard to apply a shared standard, to control which parts may be changed, and to update policies safely when the standard changes.

Schema Templates move the standard outside any one policy. This supports:

* reusable schema standards across policies;
* schema and field restrictions enforced in both the interface and the backend;
* detaching from a template without losing the imported schemas;
* template versioning, with a preview of what an update would change;
* policy import and export carrying the exact restrictions that were active at export time.

## How it works

A Schema Template is stored as its own entity with a name, description, status, version, previous version, topic ID, message ID, owner, creator, and configuration. It gets its own Hedera topic. Published template content follows the normal Hedera and IPFS publication flow.

Template schemas are ordinary schemas held in the template rather than in a policy. Each template schema has a stable `templateSchemaId`, and each template field a stable `templateFieldId`. These identifiers are the logical reference used when schemas are copied into policies and when versions are compared.

### Restrictions

Template configuration is a map keyed by template schema:

```json
{
  "schemas": {
    "template-schema-id": {
      "schemaSettingsLocked": true,
      "customFieldsLocked": false,
      "fields": {
        "template-field-id": {
          "locked": true
        }
      }
    }
  }
}
```

| Setting in the interface    | Key                      | Effect                                                                                                                                             |
| --------------------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Change schema settings**  | `schemaSettingsLocked`   | `true` prevents changes to the schema name, description, and entity type.                                                                          |
| **Can add custom fields**   | `customFieldsLocked`     | `true` prevents a policy author from adding fields of their own to the schema.                                                                     |
| **Can edit selected field** | `fields[fieldId].locked` | `true` prevents editing or removing that individual template field. Template-owned fields are locked by default; set it to `false` to allow edits. |

### Applying, updating, and detaching

When a template is applied to a policy, the template schemas are copied into the policy's topic as policy schemas. The copies keep their template identifiers, and sub-schema references are rewritten so the copies point at each other rather than back at the template.

A policy-specific snapshot is then created, and that snapshot, not the template itself, is the source of truth for restrictions in the policy editor. This matters because a draft template can keep changing while an already-applied policy should not change silently underneath its author.

The policy stores a lightweight binding: template identity, snapshot ID, state hash, the time it was applied, and a map from template schema IDs to the copied policy schema IDs.

When an applied template is updated, MGS compares the template version you select, the snapshot currently applied to the policy, and the current policy schemas. The preview groups the differences by schema and by field. Locked template fields and locked schema settings are overwritten by the template. Permitted custom fields are preserved, and custom fields are removed if the new configuration no longer allows them. Removed template schemas that carry policy custom work need a decision from you before the update completes.

When a template is detached, the binding and snapshot are removed and the template metadata is cleared from the schemas and fields. The imported schemas remain, as ordinary editable policy schemas.

## Key distinctions

* Schema Templates are standalone entities, not another tab on the Schemas page.
* `templateSchemaId` identifies the logical template schema across copies and versions; `templateFieldId` does the same for a field.
* Locks in the policy editor come from the applied snapshot, not directly from the mutable template.
* Draft template changes do not automatically change already-applied policies.
* Published templates are immutable. Changing one means creating a new draft version.
* Detaching keeps the imported schemas but removes every restriction.
* A schema owned by an applied template cannot be deleted before the template is detached.
* A policy with an applied template offers **Update Schema Template** and **Detach Schema Template** in place of **Apply Schema Template**.
* A policy linked to a draft template, or to an unresolved snapshot, cannot be published.
* On policy import you can link to a matching template, select a local template, or detach the restrictions.

## Troubleshooting

**Why can't I delete a schema template?**\
The template is in use by one or more policies. Detach it from every listed policy, then delete the template.

**Why can't a policy import link to its template?**\
The referenced template is not available on this instance. In the import preview, select a matching local template, or detach the template restrictions to continue.

## Related

* Task: [Create a Schema Template](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-templates/create-a-schema-template.md)
* Task: [Apply a Schema Template](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-templates/apply-a-schema-template.md)
* Task: [Update an Applied Schema Template](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-templates/update-an-applied-schema-template.md)
* Task: [Detach a Schema Template](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-templates/detach-a-schema-template.md)
* Task: [Import a Schema Template](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-templates/import-a-schema-template.md)
* Task: [Export a Schema Template](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-templates/export-a-schema-template.md)
* Concept: [Schema Editor](/technical-information/users/standard-registry-users-schemas-and-policies/schemas/schema-editor.md)
* Guide: [Creating a Policy using Policy Configurator](/technical-information/users/standard-registry-users-schemas-and-policies/policies/creating-a-policy-using-policy-configurator.md)