Skip to content

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.

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.

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.

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.

A validation warning naming a character the PDF engine cannot draw

  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>.

Proof PDF preview

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.

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. The button appears once the version is Ready.
  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.

Active release

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.