Proof, publish and versions

A template goes to end users only when you publish it. This page covers the three gates in between: validation, the proof, and the publish that freezes a release.

Validation

Sliick Docs validates your template every time you save, and again when you proof or publish. It checks that every merge field, theme reference and inline expression still resolves, and that block-level styling is within bounds, so problems surface before generation rather than during.

The right rail shows the current state (Valid, Warnings, Errors) with a plain-English summary you can act on. Unresolved merge fields are treated as errors so they never silently render as blanks at runtime.

Preview, Proof and Publish are hard-stopped when validation has open issues. Broken templates cannot leak past the editor.

A merge-field problem in the running header or footer says which one: “Fix the header of this template.” or “Fix the footer of this template.”, followed by the same sentence the body would give. If you are upgrading from 2.10 or earlier, a template that has been publishing with a typo in its header or footer refuses its next publish even though the canvas looks fine. The live release keeps generating meanwhile.

Two shapes that could never work are refused when you save: a Show if condition that reads a related list outside a repeat over that list, and a repeat filter the document cannot read. See Repeats and conditional content.

Merge fields inside a callout or a list item are checked exactly like any other: the field has to exist and you have to be able to read it, so a nonexistent field in one of those places is caught while you author rather than rendering as a blank in a finished document. Built-in fields such as {{Today}}, {{Now}} and {{RunningUser.*}} are valid inside callouts, list items and repeats.

Symbol glyphs

A pasted ✓, ☑, ☐, ● or similar character is checked too. A character that genuinely cannot be drawn, an emoji being the usual case, is surfaced as a warning naming the character, rather than being silently absent from the printed page. Header and footer content is scanned the same way.

It is a warning rather than an error because Word output is unaffected, so it does not block Preview, Proof or Publish. It tells you to replace the character with ordinary text, or to generate Word instead, before anyone reads the PDF.

Chinese, Japanese and Korean text is not affected: it renders in generated PDFs, breaks across lines properly, and needs nothing from you.

Generate a proof

1. Save your changes.
2. Click Generate proof in the top bar. For templates that allow both PDF and Word, the proof modal generates both formats so you can review each output path.
3. Review the resulting file or files. Proofs are saved to Salesforce Files as <Template Name> - v<Version Number> - Proof - <Record Id>.<ext>.

A version becomes Ready when validation is Valid and the version has been proofed against its test record at the current saved content. Saving after proofing drops the version back to Draft until you re-proof.

The proof decides whether the PDF goes live

A proof records which formats it actually produced, and a publish with Allow PDF output on needs a proof that produced the PDF. Otherwise Publish refuses with “Generate a proof to review the PDF, then publish.” Word is not gated this way: a proof made as PDF only still publishes after you switch Word on.

So if you publish a template as Word only and later turn Allow PDF output on, nobody can generate a PDF from it until you generate a new proof that includes the PDF and publish again. People can still generate Word documents from it in the meantime, and the record page offers only the Word button until then.

Releases published before 3.0 are left as they were. A draft proofed before the upgrade that wants PDF needs one more proof, because the older proof did not record its formats.

Publish

Publishing freezes your current draft into a new, immutable release and makes it the active version in the same step. Releases never change after publish, so a document generated today will look identical when re-generated next year.

1. From the editor, click Publish in the top bar. On a designed template the button is enabled once the version is Ready. On a Word-file template it stays clickable and names the missing step when you click it.
2. Confirm. Sliick Docs creates the release, snapshots the theme alongside it, and switches end users onto the new version, all in one step.
3. The editor goes read-only. A + Create draft button replaces Publish when you are ready to iterate again. This works for Word-file templates too: the new draft starts from the Word file already stored on the template.

While Publish is running, the right rail is read-only, so nothing typed there during a publish is lost.

Roll back

To roll back, point the template at a prior release. Clearing the active release takes generation offline for that template. Past releases are preserved for audit.