Managing Templates

Once a template is live, the work shifts from authoring to maintenance: tracking versions, keeping categories tidy, cloning safely, and knowing who can change what. This article is the reference for that work. Authoring the document itself, writing the .docx and tagging it, happens in the Word add-in and is covered separately.

Template work is split across two surfaces:

• Word add-in (Templates list). Where templates are authored and edited: write the .docx, tag it, run Parse, and use Save & Upload to push the document and its config. Version, category, clause numbering, currency, and header/footer settings all live here, on the template’s Settings tab.
• Web app (Templates → Manage). A lighter administrative view: review a template, adjust its clause risk profiles and notes, download the source document, or delete a template. It does not author or re-tag the document.

The Word add-in is the source of truth for the document and its tags; the web app Manage view is for oversight and housekeeping.

Every template carries a version number using semantic versioning, starting at 0.0.1, set on the Settings tab in the Word add-in. Versioning is manual: Pactly never bumps the number on save, so it means whatever your team decides, for example raising the minor part for approved-language changes and the patch part for small fixes.

The version is a record-keeping label, not a control. Editing a template updates the single template in place rather than spinning off a new live version, so to keep an audit trail of what the document looked like at a point in time, use backups.

Each template has a Backups tab in the Word add-in holding point-in-time snapshots of the document and its config. A backup can carry a short comment, so you can record why the snapshot was taken (for example, “before renumbering Section 4”). Backups are the safety net for template edits: if a change goes wrong, you have the prior state to refer back to.

Individual clause edits made through the platform are tracked separately and can be rolled back, a finer-grained safety net than backups, scoped to one clause at a time. Rolling back a clause edit is restricted to administrators (see Permissions) and is not part of the everyday generation flow.

A template can be assigned a Category on its Settings tab. The category is the contract classification (NDA, MSA, employment agreement, and so on) that your organization defines centrally.

The key behavior: the generated contract inherits the template’s category. The resulting Template Contract is filed under whatever category the template carries, with no extra step from the requester, which keeps your repository consistently categorized. Changing a template’s category changes the classification of every contract generated from it afterward, but not contracts already generated, which keep the category they were created with.

You can clone an existing template to use it as the starting point for a new one. The clone copies the document and its full configuration (variables, value maps, rules, parties), then becomes an independent template you edit on its own.

Cloning is the right tool when you genuinely need a separate, differently-structured agreement. It is the wrong tool for small variations of the same agreement, for example three flavors of an NDA: maintaining near-identical clones means every future change has to be made in each copy, and they drift apart over time. For variants of one agreement, prefer a single template that branches internally using value maps and rules, so an approved-language change is made once. See Conditional Logic and Rules for how that branching works.

This is the maintenance fact that catches people out most often: template edits affect newly generated contracts only. When you change a template, every contract generated after the change reflects it; contracts already generated are unchanged. They are independent documents in the repository, not live views of the template.

If an existing contract needs the updated language, it has to be regenerated from the template. There is no automatic re-flow of template edits into contracts already in the repository, so plan template changes with this in mind, especially mid-negotiation.

Access to templates is governed by the template.* permissions on a role, scoped to your own organization. The boundaries fall into three groups.

The base authoring permissions cover the everyday work of building and maintaining templates. The two clause-level actions are deliberately narrower and restricted to administrators, because they change the template’s language directly. Requesters and approvers can see templates but cannot author them; they consume templates through the generation form.

When a template has tagging problems (a malformed token, a reference to something that does not exist, a duplicate ID), they surface in the Errors tab in the Word add-in, with the count shown on the tab and each error located in the document. A clean template shows no errors there.

An unresolved token does not stop generation. Instead the affected tag renders as a bullet-in-circle placeholder, [●], in the output document. If generated contracts come back with [●] marks where real values should be, the fix is in the template (an unmapped or mistyped tag), not in the contract: check the Errors tab and the tag in question.

• Templates Overview
• Conditional Logic and Rules
• The Option Sync Trap
• Field Mappings and Naming
• Properties & Categories