Sliick Docs: Complete User Guide

Version: Updated for Sliick Docs v2.1.0, live on the Salesforce AppExchange. This guide is cumulative: it covers everything in the product today, not just the latest release. Highlights added since v1.2 include running headers and footers with page numbers, multi-level nested data with a live preview and rich-text fields, table-row repeats and merged table cells, a flexible columns block, running-user and date built-ins, conditional else branches, find and replace, template folders, template-level compliance controls (audience visibility, per-record targeting, output-format lock), cross-org template portability, and a localised interface across more than ten languages. The latest v2.1 release adds record-file evidence packs (embed every file on a record, or each child record, as a photo grid inside the document), a premium high-volume rendering path for large image-heavy documents, the option to store generated documents in your own cloud storage, and native e-signature, currently in closed pilot.

Sliick Docs brings native, versioned document generation to your Salesforce org. Admins design templates in a WYSIWYG editor and publish them as immutable releases; business users generate the resulting PDF or Microsoft Word file in one click from any record page; list-view mass actions and Flows generate them in bulk; and the auto-email pipeline routes the finished file to the right recipients automatically. v2.1 extends this from a document generator into a document platform that can also collate a record’s files into evidence packs, generate large image-heavy documents at scale, keep output in your own storage, and (in closed pilot) send documents for signature. This guide is the complete reference for everyone who touches the product.

Guide overview

1. What is Sliick Docs?
2. Quick start: generate a document from a record
3. Install, permission sets, and the org-wide theme
4. Authoring templates
5. Record-file evidence packs
6. Templates, Bundles, and Batches: the three units of work
7. Bulk generation with Doc Batches
8. List-view mass action
9. Multi-template Doc Bundles
10. Auto-email after generation
11. Flow integration: three Flow actions
12. Microsoft Word (.docx) output
13. Generation at scale and your own storage
14. Native e-signature (closed pilot)
15. Compliance: access controls, audit log, and retention
16. Analytics dashboard
17. Template and Bundle portability: Export and Import
18. A localised interface
19. Security and trust
20. Troubleshooting and reference

What is Sliick Docs?

Sliick Docs is a 100% native Salesforce document-generation app. Everything runs inside your org. Both PDF and Microsoft Word files are generated natively on the platform. No document content ever leaves your boundary or passes through a third-party service.

Key concepts:

• Template: one per logical document type (Account Summary, Quote Cover Letter, Work Order). Admins edit a template; end users generate from it. Each template can be configured to allow PDF output, Word output, or both.
• Draft and Release: while a template is being edited it lives as a draft. Publishing creates an immutable Release: a frozen snapshot the runtime renders from. Drafts can change freely; releases never do.
• Active Release: the release currently serving end users. Switching versions or rolling back is a single, fully audited change.
• Bundle: a named, ordered collection of templates rendered together against a single record as one combined PDF. Bundles publish to immutable releases too.
• Batch: a bulk run that produces many files from one template (or one bundle) against many records.
• Generation: the audit record for one rendered file, surfaced via the Generations tab. Tracks who generated what, in which format, from which template release, against which record, and the email outcome if auto-email is enabled.
• Base object: every template (and bundle) is anchored to a single Salesforce object. Merge fields and runtime data come from records of that object.
• Evidence pack: a document whose image block embeds every file attached to a record (or to each child record), collated into one PDF. See Record-file evidence packs.
• Storage: generated documents are saved to Salesforce Files by default. With Sliick Files installed, evidence-pack photos can be read from, and generated documents written to, your organisation’s own connected cloud storage.

There are four ways to generate a document: from a record page (one click), from a list view (tick records and click a mass-action button), from the Doc Batches console (admin bulk), or from a Flow (record-triggered, scheduled, or screen). All four share the same rendering engine, so what your admin sees in proof is what every recipient gets. Documents can also be sent for native electronic signature, currently in closed pilot.

Quick start: generate a document from a record

The fastest path from a fresh install to a generated file, assuming an admin has already done section 3 below.

1. Open a Salesforce record on an object that has a published Sliick Docs template (Account, Opportunity, your custom object).
2. Find the Sliick Docs Generator component on the record page.
3. Pick a template from the list (only templates with an active release for this object appear).
4. Click Generate PDF or Generate Word depending on what the template allows. If only one format is enabled you see a single button; if both are enabled you see a split button and pick at runtime.
5. The file appears in the Files related list. Click to open or download.

That is the end-user experience. Everything else in this guide is about giving admins the tools to design those templates well and to scale generation up to bulk, automation, multi-template bundles, and compliance-grade audit.

Install, permission sets, and the org-wide theme

Install the package

Install from the Sliick Docs AppExchange listing.

When prompted, install for All Users (or Admins Only if you want a controlled rollout, then assign the relevant permission set per user).

Permission sets

Three permission sets ship with the package. Assign each user the one (or two) that match their role.

Assign from Setup > Users > Permission Sets.

Tip: in production, treat Sliick_Docs_Admin as a privileged role for a small group of template authors. End users only ever need Sliick_Docs_User. The running user of every Sliick Docs Flow needs Sliick_Docs_Automation.

Set the org-wide theme

Open the Sliick Docs app from the App Launcher and click Settings. The Brand & theme panel controls the palette every template inherits.

Theme changes take effect the next time a template is published. Existing releases keep the theme they were published with, so historical PDFs remain reproducible even after a rebrand.

Open the Template Library

Open the App Launcher and select Sliick Docs. The default landing tab is the Template Library. The other top-level tabs you will use are Doc Bundles, Doc Batches, Generations (formerly Jobs), Analytics, and Settings.

The Template Library’s right-rail help pane carries a Starter templates card linking to a gallery of six ready-to-import templates - Sales Proposal (Opportunity), Account Statement, Welcome Letter (Contact), Lead Follow-up, Case Summary, and Order Confirmation. All six are built on standard Sales and Service objects with no custom fields, so they import cleanly into any sandbox.

Authoring templates

Create a template

A template is anchored to a single base SObject (for example Account, Opportunity, or any custom object). Every document the template generates is for one record of that object.

1. Open the Template Library and click New template.
2. Give the template a clear name (this becomes part of the generated PDF file name). Names are unique across the org, case-insensitive.
3. Choose the Base Object the template will run against.
4. Click Create. Sliick Docs creates the template and an initial draft, then opens the editor on that draft.

Note: the base object cannot be changed after creation. If you need a different base object, create a new template.

Editor anatomy

The Template Editor has four regions:

• Top bar: Save, Generate proof, Preview, Publish, undo / redo, history drawer, test record picker, and find and replace.
• Left rail: Blocks palette and a dedicated, searchable Merge fields panel.
• Designer canvas: the page being authored. A Body / Header / Footer switcher chooses which surface you are editing, and blocks can be reordered by dragging them on the canvas.
• Right rail: Page settings and the Properties / Block style panels for the selected block.

A pinned inline formatting toolbar sits above the canvas whenever a styleable block is selected. Every change is tracked in a document-level undo / redo history (Cmd / Ctrl + Z, and Cmd / Ctrl + Shift + Z), and each editing surface keeps its own history.

Pick a test record

Every draft needs a test record so proofing can render against real data.

1. In the top bar, click the Test record picker.
2. Pick any record on the base object. Use a record with realistic data including any parent lookups or child collections you reference.

The selection is saved with the template and reused across draft sessions. Picking a test record is a prerequisite for publishing.

Block reference

Drag blocks from the Blocks tab on the left rail, or click + Add block inside any container. Every block is selectable; the right rail switches to its Properties and Block style panels on select.

Block-level styling

Every styleable block exposes a Block style section in the right rail. The controls render live in the canvas so what you see matches what the PDF will contain.

Theme references (brand.primary, theme.headingColor) resolve at compile time, so an org-wide theme change repaints every block using those references the next time the template is published. Hex codes are literal one-offs that do not track theme changes.

Inline formatting toolbar

When you select a text, heading, table cell, callout, or other styleable block, a toolbar pins itself above the canvas.

The per-run controls work in two modes: highlight a range first then click a control (Selection mode), or with just a caret click a control to arm it (Toggle-then-type mode). Active / Mixed / Off states reflect the selection: a Mixed underline button means part of the selection is underlined and part is not.

Merge fields

Merge fields are first-class objects in Sliick Docs. They are stored as structured chips inside text runs, not as plain text placeholders, so they cannot be accidentally broken.

To insert a merge field:

1. Click into a Text, Heading, or table cell block.
2. Open the Merge fields tab on the left rail (or type {{ to open the autocomplete).
3. Search by label or API name and click the field to insert it.

Scope of merge fields

• Root scalar fields on the base object.
• Parent lookup fields up to five hops (for example Account.Owner.Profile.UserType.Name). Works at root scope and inside Repeat scope.
• Child collections rendered via Repeat for each blocks, including nested repeats to arbitrary depth (each opportunity and its line items, each case and its comments) and iteration across junction objects. A scope-aware field picker follows your cursor and only offers fields that resolve at the current level.
• Conditional visibility via Show if (cond) blocks, with an optional else branch (see grammar below).
• Aggregate functions over child relationships: SUM, COUNT, AVG, MIN, MAX, with an optional Format. Aggregates resolve identically in PDF and Word output.
• Running-user fields via {{RunningUser.*}} (name, title, email, phone, manager), so a “Prepared by” line follows whoever generates the document across record-page, Flow, and batch generation.
• Date and time built-ins: {{Today}} and {{Now}} insert the current date and time in the running user’s time zone, with optional formatting.
• Approval history: a Repeat block can render a record’s Salesforce approval history (approver, comments, and date) with no custom code - useful for contract cover sheets and sign-off summaries.
• Rich-text fields: Long Text Area fields that hold formatted HTML are auto-detected and rendered with their formatting in both PDF output and the canvas preview.
• Image merge fields: any Salesforce image or URL field can be rendered as an inline image (toggle in the chip popover) or as a standalone Image block via the block’s Source -> Merge field toggle.
• Hyperlinks: text or merge-field chips can be turned into a hyperlink; merge-field placeholders are allowed inside the URL (https://salesforce.com/{{Account.Id}}).
• Barcodes and QR codes: standalone blocks bound to any merge field; the resolved value is encoded into the document natively.

Field-level security

Sliick Docs always honours your Salesforce permissions. When an admin browses for merge fields, they only see fields they themselves can read - so two different admins may see different field lists depending on their access. If a field you expect to see is missing, ask your Salesforce admin to check your profile or permission sets.

Format dropdown

Every scalar merge-field chip carries a Format dropdown alongside the fallback input. The format choice applies at PDF render time using the running user’s locale; the chip’s stored value is untouched.

Fallback text

The same chip popover offers a Fallback text input. If the resolved value is blank at runtime, the fallback renders instead. Useful for Account.Phone with a fallback of (no phone on file).

Image merge fields

To merge a Salesforce image or URL field as a dynamic image inline within text:

1. Insert the merge field chip as usual.
2. Click the chip to open its popover.
3. Toggle Render as image. Width and height inputs appear.

At generation the chip resolves to the field’s image. Image merge fields work the same way inside Repeat scope: each iteration resolves to its own image.

Image block with merge-field source

For per-record letterheads, signatory logos, or hero images that appear as a standalone block (not inline within a text run), use the Image block’s Source toggle:

• Static file (default) - the same image on every doc, picked from a Salesforce File.
• Merge field - the image varies per record. Bind any field that points to a Salesforce image file.

This makes per-record letterheads “just work” against any image field. Pair with auto-email and a letterhead field on Account to send branded statements without a separate template per account.

Barcodes and QR codes

Sliick Docs ships dedicated Barcode (Code 128) and QR Code (ISO 18004) blocks in the Block Kind Picker. To add one:

1. Click + Add block and pick Barcode or QR Code.
2. In the right rail, bind the block to any merge field (the field whose value will be encoded).
3. Set width, height, and alignment.

Encoding is fully native - no external services, no static images, and no callouts - and renders reliably in the generated document. Both block types respect Repeat scope, so per-row barcodes for shipping labels or asset tags are a one-line change.

Barcodes and QR codes are PDF-only - the validator rejects a template that enables Word output when either block is present. Authors typically split templates: the PDF-only variant carries the barcode, the Word-friendly variant doesn’t.

Hyperlinks

Turn text or merge-field chips into a hyperlink via the link button in the inline toolbar. URLs accept merge-field placeholder tokens, for example https://help.example.com/account/{{Account.Id}}. The merge fields inside the URL resolve per record.

Lists

Bulleted and numbered lists are first-class blocks. Each list item is a text run that supports merge field chips and inline formatting.

Conditional content (Show if)

A Show if block conditionally renders its children based on parent-record data. Expressions are parsed at save time, so any syntax errors surface in the right rail as plain-English messages while you author.

Operators: =, !=, >, >=, <, <=, contains (case-insensitive substring). Literals: single-quoted strings, decimals (including negative), true, false, null.

A Show if block carries an optional else branch: a single block renders one set of children when its condition is met and a different set when it is not, instead of two separate blocks kept in sync with inverted expressions.

Repeating sections

A Repeat for each block loops over a child relationship of the base object. The block’s children render once per row (one row per Opportunity Line Item, one row per Contact, and so on).

• Source relationship: pick from the dropdown of available child relationships. The list only shows relationships you have access to. You can also insert a related list straight from the Merge fields panel, which wraps the selection in a Repeat for you.
• Filter (optional): narrow the rows that render, for example Opportunities.StageName != 'Closed Lost'.
• Render mode: a repeat can render as stacked blocks or as table rows (one row per child record), which is the layout invoices, statements, and order summaries reach for.
• Inside a Repeat block, the Merge fields panel flips to show the child object’s fields. Insert chips like {{Opportunities.Amount}}; they resolve per row at runtime.
• Five-hop parent lookups also work inside Repeat blocks, for example Opportunities.Account.Owner.Profile.Name.
• Nested repeats are supported to arbitrary depth - for example an Account that repeats over its Opportunities, each of which repeats over its line items. Sections, callouts, and conditional blocks can sit inside a repeat.

Signatures

A signature block renders a 2+ signer area with top-bordered lines and merge-field signer labels (for example Account.Name for the customer line, Account.Owner.Name for the rep line). Add or remove signers in the right rail; minimum two.

Watermarks

In the right rail Page settings, the Watermark controls let you stamp every page of the generated PDF. Set a text watermark (text, colour, opacity, font size) for DRAFT, CONFIDENTIAL, copyright lines, or document-classification labels, and optionally an image watermark sourced from a file already in Salesforce, with adjustable opacity. The two can combine - for example a brand logo paired with a “DRAFT” stamp. The editor preview matches what the document will contain. Theme references and merge-field chips are not supported inside the watermark text (string only).

The image watermark is honoured by both PDF and Word output; the text watermark is PDF-only, so a template with a text watermark cannot enable Word output, and the validator surfaces this at save time. Admins typically split a template when both an editable-Word workflow and a stamped-PDF version are needed.

Inline image sizing and on-canvas previews

Inline images offer five sizing modes that render identically in PDF and Word output, and static images preview directly on the design canvas while authoring, so authors see the real image without switching to preview mode.

Headers and footers

Documents can carry running headers and footers that repeat on every page, with page numbers and dynamic merge content - an account name in the header, a page count in the footer, or both. Use the Body / Header / Footer switcher above the canvas to edit each surface directly. A different-first-page toggle omits the header and footer from a cover page, the usual layout for proposals and statements.

Columns

The Columns block lays content out in two or three columns with custom widths. Native stepper arrows adjust the width and gap, widths auto-redistribute to total 100% as you change any one (with a 10% minimum per column), and the gap renders live on the canvas. Templates built with the older fixed two-column block keep working unchanged.

Merged table cells

Table cells can be merged horizontally to build colspan title bands and total rows. Select a cell and use Merge right and Split in the cell properties panel; each option enables only when the merge maths allows it. The canvas renders merged cells at their true width, and adding or removing columns stays in lockstep with the merged geometry so a table never corrupts silently. Vertical merge (rowspan) is not supported; horizontal merging covers the title-row and total-row patterns most templates need.

Live canvas preview

With a test record selected, the canvas previews real merged values as you author: field chips show the evaluated data rather than field-name labels, a repeat renders its first row with a “Showing 1 of N” badge, conditional branches render selectively against the test record, and aggregates run against the full child collection. An amber nudge bar appears when no test record is set. The preview refreshes when you save.

Find and replace

Open find and replace from the top bar to search the text in a template and replace it in place, stepping through each match with an option to match case. Matches are highlighted on the canvas and the canvas scrolls to the active match. It is a quick way to update a product name, a legal phrase, or boilerplate across a longer template. Find indexes body text and headings.

Template folders

The Template Library supports folders so a library that has grown across several teams stays easy to navigate. Create, rename, and delete folders, and move templates between them. Unfiled templates appear under an “Uncategorised” view, and an “All templates” view still shows everything at once.

Validation, proof, and the Ready state

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. Multi-line toast formatting renders each validation message on its own line instead of running them together.

To 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(s). Generated proofs are saved to Salesforce Files with the file name <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 contract. Saving after proofing drops the version back to Draft until you re-proof.

Publishing

Publishing freezes your current draft into a new, immutable release and atomically makes it the active version. 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’re ready to iterate again.

To roll back, point the template at a prior release (or clear it to take generation offline for that template). Past releases are preserved for audit.

Record-file evidence packs

An Image block can embed every file attached to a record - the base record, or each child record inside a Repeat - as a clean photo grid inside the generated document. This turns a template into a collated evidence pack: think quarterly warranty claims by manufacturer, site-inspection reports, insurance evidence, project handovers, or compliance bundles, produced in one click.

Add an evidence-pack gallery

1. Add an Image block where the photos should appear (inside a Repeat block if you want one gallery per child record).
2. Set the block’s Source to Files on this record.
3. Configure the grid: number of columns (1 to 6), thumbnail size, an optional cap on how many files to include, and whether to show file-name captions.

A template like Account → Repeat(Cases) → case details + gallery renders each case’s details followed by a grid of that case’s photos, all collated into one document.

Where the photos come from

The gallery resolves a record’s images from either source behind one setting:

• Salesforce Files - the files attached to the record in the standard way. This works out of the box, with nothing extra installed.
• Your connected cloud storage - when Sliick Files is installed, photos are read from whatever storage your organisation has connected, whether that is Sliick Cloud Storage, SharePoint, Amazon S3, Google Cloud, or Azure. Sliick Files simply widens where the photos are allowed to live; the evidence-pack feature itself works with or without it.

Volume and delivery

Evidence packs are built to handle photo-dense documents - dozens or hundreds of images in a single pack - without the limits that constrain ordinary on-platform generation. For the largest packs, enable the premium high-volume rendering path described in Generation at scale and your own storage. The finished document is saved to Salesforce Files, or to your connected cloud storage when Sliick Files is installed, and linked to the record as usual.

Drop the Document Pack Generator component on a record page to let end users produce a pack in one click; access is gated by the premium permission.

Templates, Bundles, and Batches: the three units of work

It is worth naming the distinction up front.

• Template is the unit of authoring. One template renders one PDF for one record at a time.
• Bundle is the unit of composition. One bundle stitches several templates together into a single combined PDF for one record. Bundles publish to immutable releases too.
• Batch is the unit of bulk. One batch runs one template (or one bundle) against many records. Each batch has its own status (Queued, Running, Merging, Succeeded, Partial Success, Failed, Aborted) and tracks one job per record.

Behind the scenes all three follow the same path: load the record, evaluate any conditional or repeating sections, substitute merge fields, render using the native Salesforce PDF engine, save to Salesforce Files. The difference is who initiates and how many records are covered.

Bulk generation with Doc Batches

The Doc Batches tab is where admins submit and monitor bulk runs.

Submit a new batch

1. Click New batch.
2. Pick a template (only templates with a published release appear) or a bundle.
3. Pick a source:
   • By filter: type a record filter (a Salesforce WHERE clause), or leave it blank to target every record of the base object.
   • By report: pick a tabular Salesforce report (up to 2,000 rows).
   • By record IDs: paste a list of up to 2,000 record IDs (also available from the Flow action).
4. Pick a batch size (1 to 200, default 1).
5. Pick an output mode:
   • Individual (default): one PDF per record, attached to that record.
   • Combined PDF only: one merged PDF attached to the batch row; no per-record files.
   • Both: one PDF per record plus a combined PDF.
6. (Optional) Pick an Output Format: PDF (default) or Word. Word batches require Individual mode.
7. Click Analyze.

The pre-flight verdict shows release readiness, record count against the 50,000 cap, and (for Combined / Both) a size estimate. Combined-output batches with more than 50 records are flagged upfront with an actionable “Switch to Individual mode” message instead of failing partway through a large run.

Spot-check sample

From the verdict, click Preview sample to step through up to 5 sample records and see exactly how each will render. This catches merge-field problems before generating 500 PDFs.

Monitor

The batch monitor refreshes every 5 seconds. The header shows a status badge and progress bar; the per-record table updates as each record completes. While the run is in flight, Cancel is available and Sliick Docs stops the underlying job as soon as it can.

When the run terminates, the recent-batches sidebar updates and a Sliick Docs Batch notification is sent to whoever submitted it.

Download

• Individual / Both modes: Download all as ZIP is available on the monitor. Sync up to 50 records; asynchronous above (a notification fires when the ZIP is ready). Each batch also lists per-record files inline.
• Combined / Both modes: the combined PDF is on the batch row itself, available as a single download.

Retry failed

After a batch ends as Partial Success or Failed, expand the row and click Retry failed. If the template has been republished since the original run, Sliick Docs surfaces that in the confirmation dialog so you can decide whether to re-run against the original release or the new one. The new batch links back to the original so you can trace retry chains. Capped at 2,000 failed records per retry.

Limits worth knowing

List-view mass action

Admins can add a one-line custom list button (URL /flow/Generate_Sliick_Docs_From_List_View) to any object’s list views so end users can tick records and trigger a batch generation in one click - no Flow build, no admin involvement at runtime.

Add the button

1. Setup -> Object Manager -> pick the object (Account, Opportunity, Contact, Case, Lead, Order, or any custom object).
2. Buttons, Links, and Actions -> New Button or Link.
3. Display Type: List Button with Display Checkboxes (for Multi-Record Selection) ticked.
4. Behavior: Display in existing window with sidebar. Content Source: URL.
5. URL: /flow/Generate_Sliick_Docs_From_List_View.
6. Save, then add the button to the list view’s Search Layouts -> List View layout.

The same button URL works for every object - the object type is detected automatically from the records you select.

Use it

1. From any list view with the button installed, tick up to 200 records.
2. Click Generate Sliick Docs in the list-view button bar.
3. Pick a template that matches the object’s base object and an output format (PDF or Word).
4. Submit. The batch lands in the Doc Batches console with full status monitoring.

Multi-template Doc Bundles

A bundle is a named, versioned bundle of templates rendered together against one source record to produce a single combined PDF. A Sales Bundle might combine a cover letter, the actual quote, the terms and conditions, and an optional NDA addendum.

Create a bundle

1. Open the Doc Bundles tab.
2. Click New bundle.
3. Fill in the display name, base object API (every member template must share this base object), and an optional description.
4. Click Create.

Add templates to a bundle

1. On the bundle card, click + Add template.
2. Pick a template that shares the bundle’s base object. Templates already in the bundle are filtered out.
3. Set Required or Optional. Required = the bundle fails if the template is inaccessible. Optional = soft-skip and continue.
4. Click Add. The item appends to the end.

Reorder items with the up / down arrows on each row. Remove items with the trash icon.

Per-item inclusion expressions

Each bundle item can carry an optional inclusion expression (same grammar as the Show if block, for example Account.Industry = 'Technology'). The expression is frozen into the bundle release at publish and evaluated at runtime against the source record. Items that evaluate to false are silently skipped from the combined PDF.

Publish a bundle

Click Publish on the bundle card. Sliick Docs snapshots each member template’s current active release into the new bundle release. Once published, the bundle renders the same way every time, even if a member template is later republished.

Drift handling

Bundle releases are immutable by design. When a member template is republished after the bundle was published, the bundle does not auto-update. Instead:

• The bundle library card shows a yellow Members updated badge with a tooltip listing affected templates.
• A one-click Republish with current members action produces a fresh release that re-snapshots all current member releases.
• The retry-failed confirmation dialog on the Doc Batches console calls out drift in the same way.

Bundle runtime

Single-record bundle generation is available through the Generate Sliick Bundle Flow action (section 9). Bulk bundle generation is available through Generate Sliick Docs (Bulk) (pass the bundle instead of a template) or directly from the Doc Batches console.

Auto-email after generation

Configure email-on-success per template via six fields on the Template record.

When generation succeeds for a record (single or batch), Sliick Docs sends the email automatically. The subject and body come from your chosen Email Template (with full merge-field support against the source record); the generated PDF is attached.

Every record’s job carries an email audit trail:

Behaviour on failure: if generation succeeds but the email fails (for example the recipient field is blank), the document still counts as successfully generated and the file is saved. The Email Status field records the failure separately. The batch’s overall status rolls up: any failed email flips the batch to Partial Success even when every document generated cleanly.

Daily limit. Salesforce caps single-recipient emails at 5,000 per 24 hours, org-wide. A batch that would exceed the daily allotment is flagged in the pre-flight analyzer.

Flow integration: three Flow actions

Sliick Docs ships three Flow actions for use in Record-Triggered, Scheduled, and Screen Flows. All three are designed to never throw. Failures are returned cleanly as success=false plus an errorMessage, so your Flow can branch on the outcome rather than halting the whole transaction when something goes wrong.

Generate Sliick Doc (single record, synchronous)

Outputs: jobId, contentDocumentId (the saved file), success, errorMessage.

Generate Sliick Docs (Bulk) (asynchronous; returns the batch ID immediately)

Outputs: batchId, success, errorMessage.

One important Flow-authoring rule: pass your record collection to the bulk action once, not inside a Loop. Wrapping the bulk call in a Loop creates one batch per record instead of one batch for the whole set, which is almost never what you want.

Generate Sliick Bundle (single record, synchronous)

Outputs: jobId, contentDocumentId (the combined file), success, errorMessage.

Three common automation shapes this unlocks

1. Auto-on-state (Record-Triggered Flow): Opportunity entry condition IsClosed = TRUE → call Generate Sliick Doc with templateId + [Record].Id. A closeout PDF lands on every newly-closed Opportunity automatically. Pair with auto-email to email it to the customer too.
2. Recurring batch (Scheduled Flow): daily at 2am → Get Records (Accounts updated yesterday) → single call to Generate Sliick Docs (Bulk) with the resulting collection. Customers receive an overnight statement PDF.
3. User-driven bulk (Screen Flow): picker for template, picker for filter or report → Generate Sliick Docs (Bulk) → display the returned batch ID with a follow-up link to the Doc Batches tab so the user can monitor progress.

Microsoft Word (.docx) output

Sliick Docs generates either a PDF or a Microsoft Word .docx from the same template - one source of truth, two output paths. Word files are generated natively on the platform, so no external service is involved.

Enable Word output on a template

Two flags on the Template record control which formats end users see:

A validation rule rejects the both-off state - at least one format must be enabled. Enable both to give end users a split button at runtime.

When Word vs PDF

The data inside the document is identical between formats; only the output file type differs.

Where Word output works

• Record-page Sliick Docs Generator (split button when both formats enabled)
• All three Flow actions (optional outputFormat input)
• Doc Batches console + Bulk Flow action - Individual output mode only
• Single-record bundle generation
• List-view mass action
• Dual-format proof during authoring

Word output limitations

• Combined / Both batch modes are PDF-only - use Individual mode for Word batches.
• Bundle Word uses the org default theme. Single-template Word honours per-template theme overrides correctly; bundle Word does not.
• Text watermarks and barcodes are PDF-only - the validator rejects a template that enables Word output when either is present. (Image watermarks are honoured in both formats.) Authors typically split into separate templates (one for the editable-Word workflow, one for the locked-PDF version).
• A template first published on an early version may need a one-time re-publish to enable Word output.

File-name pattern auto-swaps the extension

The per-template File name pattern doesn’t need an {{ext}} token. The extension swaps automatically based on which format was generated:

• Pattern {{Account.Name}} - Quote.pdf -> generated as Word becomes Acme Corp - Quote.docx.
• Pattern {{Account.Name}} - Quote.docx -> generated as PDF becomes Acme Corp - Quote.pdf.

Salesforce previews Word files natively, so generated .docx files render inline in the Files viewer alongside PDFs.

Generation at scale and your own storage

Everyday documents render on-platform with no setup, exactly as described elsewhere in this guide. Two premium options handle the demanding end of the spectrum: large, image-heavy documents, and high-volume output that would otherwise pressure Salesforce file storage. Both build on Sliick Files.

Premium high-volume rendering

Large image-rich documents - photo-dense evidence packs, long image-heavy reports - are the hardest thing to generate reliably inside any platform’s limits. The premium high-volume rendering path produces these through a dedicated rendering capability that is not bound by the constraints that cap standard on-platform generation, so the documents most likely to fail or time out elsewhere generate dependably.

• Enable it with a single setting in Settings. When it is on, demanding PDF generation routes through the premium path automatically; nothing changes for the author.
• Everyday documents are unaffected, and bulk batch runs stay on the native path by design.
• It applies to PDF output; Word documents always render natively.

Because this path is a premium capability, talk to us about enabling it for your organisation.

Bring-your-own cloud storage

With Sliick Files connected, generated documents can be relocated to your own external file storage instead of Salesforce Files, keeping high-volume output off the org’s storage where that matters for cost or governance. Each document stays linked to its record exactly as before. This pairs naturally with evidence packs: photos are read from your connected storage, and the finished document is written back to it.

Native e-signature (closed pilot)

Closed pilot. Native e-signature is available to a limited group of pilot customers. It stays completely out of the way until an admin opts a template in. Contact us to request a place in the pilot.

Sliick Docs can send a document for legally meaningful electronic signature without leaving Salesforce - no separate DocuSign or Adobe subscription, and all signing data stays in your org.

• Send for signature from a record: choose a generated document or an existing PDF, build the signer roster (name, email, role), place the fields, and route signing to everyone at once or in a set order. In-person signing on the sender’s device is supported.
• A guest signing experience on your own Experience Cloud site: each signer verifies their identity with an emailed one-time code, reviews versioned consent text, and signs - no login or account required.
• Evidence designed to be challenged: every action on an envelope is written to a tamper-evident audit trail that is re-checked automatically each night, and a Certificate of Completion records who signed, when, from where, against which consent text, and refuses to issue if the evidence does not verify intact.
• Independent verification: anyone can later confirm a signed document is genuine through a public verifier, without logging in or uploading the file. An optional sealed-document tier produces an independently verifiable, tamper-evident signed PDF for organisations that need that extra level of assurance.

E-signature requirements vary by jurisdiction and document type, and some categories of document carry special rules. Sliick Docs provides signing capability and evidence tooling, not legal advice. The pilot is the right time to work through whether it fits your document types.

Compliance: access controls, audit log, and retention

Sliick Docs ships template-level access controls for compliance teams, plus two opt-in capabilities for regulated industries: a fingerprinted audit log of what got merged into each document, and a per-template retention sweep that permanently deletes aged files.

Template-level access controls

Three controls apply across every generation path - record page, batch, Flow, and list view:

• Audience visibility: restrict a template to users who hold the right permission sets, so sensitive templates such as board packs, HR letters, or executive variants stay out of everyone else’s picker. Admins still see every template in the editor.
• Per-record targeting: scope a template to a specific set of records so it only appears, and only generates, for those records. Batch runs filter to the records in scope automatically rather than failing outright.
• Output-format lock: lock a template to a single output format so, for example, a signed contract cannot be generated as an editable Word document.

Compliance audit log

Enable it per template with the Audit Enabled checkbox. Once on:

• Every successful generation captures a fingerprinted snapshot of the resolved merge values - one per record per generation - so the contents are verifiable against the original.
• Entries are written through a protected path that users cannot suppress or forge.
• The Generations tab links each Generation to its audit entry.

Use this for contracts, regulated communications, not-for-profit donation receipts, accreditation letters, or anything that needs a verifiable “this is what we sent, and the captured values have not been altered through normal user paths” record. The fingerprint detects accidental corruption and tampering by non-administrators. As with any in-org integrity scheme, a Salesforce System Administrator retains the platform-level ability to edit their own org’s data; for evidentiary-grade tamper evidence, layer Field History Tracking on the audit records or export the fingerprints periodically to a store outside the org.

Retention policies

Set a per-template auto-delete window with the Retention Days field. 0 means retain forever; anything else is the number of days the generated file lives in Salesforce Files before the sweep collects it.

The nightly retention sweep does the work:

• Finds generations whose template carries a retention window and whose file is older than the threshold.
• Permanently deletes the generated file.
• Marks the Generation as deleted, so the audit trail survives even after the file is gone.

Two safety mechanisms:

• Hold from Deletion is a per-Generation checkbox. Tick it on a specific row to exempt it from the sweep - useful for files that have to survive an open audit window, legal hold, or dispute.
• The sweep only deletes Sliick-Docs-generated files. Other files on the record are untouched.

Schedule the sweep from Settings -> Schedule retention sweep. Pick a daily time and click Schedule.

Analytics dashboard

A new Analytics tab (admin-only) sources everything from existing generation history - no new tracking infrastructure to set up. The dashboard auto-refreshes every 5 minutes with a manual refresh available.

The failure category is recorded the moment a generation fails, so the dashboard stays fast no matter how much history accumulates. Older failures that predate categorisation show as Other until they age out of the 30-day window.

The dashboard is powered by a charting package that installs automatically alongside Sliick Docs. No extra configuration needed.

Template and Bundle portability: Export and Import

Templates and bundles are Salesforce records, not metadata, so Change Sets and SFDX deploy do not move them. The Library and the Bundles tab both ship Export and Import actions, so you can promote templates sandbox -> UAT -> production the same way you already promote code, with no paid release-management tool.

Each template and bundle carries a stable cross-org identity (External_Id), minted at creation, that survives renames and org boundaries. Import matches on that identity, which is what makes re-promotion idempotent: re-importing the same template updates it in place rather than creating a duplicate.

Export

• Template Library: every template card has a download icon, and you can multi-select to export several at once. Clicking it downloads sliick_<TemplateName>_<YYYY-MM-DD>.sdt (Sliick Doc Template).
• Bundles tab: every bundle row has an Export link. The export includes the bundle header, items, and every member template by default so the target org has everything it needs.
• An include-files option carries watermark and image bytes along in the archive. If an image is too large for the platform’s limits, the export degrades gracefully with a “re-attach in the target” note rather than failing.

Org-specific references (test record ID, auto-email recipient / CC / from-address / template IDs) are scrubbed automatically. The export is the .sdt v3 archive: a compressed file carrying a manifest plus one entry per template, version, and binary. A magic-byte router still imports older v2 JSON envelopes and the hand-editable starter sources, so earlier files keep working.

Import

1. Open the target org’s Template Library (or Bundles tab) with Sliick Docs installed and Sliick_Docs_Admin assigned.
2. Click Import Template (or Import Bundle).
3. Choose the .sdt file, then pick a conflict policy - Skip, Update, Duplicate, or Fail - for templates that already exist in the target.
4. (Optional) Run a dry-run first: Sliick Docs previews exactly what would be created, updated, or skipped and commits nothing, so you can confirm the outcome before it touches the org.
5. Click Import. A summary modal lists what was imported with any warnings (renamed-on-collision, unresolved merge fields, fields hidden by your permissions, unresolved bundle members).

Folder paths referenced by an imported template are created automatically in the target, and org-specific references such as email templates and org-wide addresses are re-pointed to the target org’s equivalents.

What an imported template starts as

• Status: Draft by default. Imported templates land as drafts so the receiving admin reviews and publishes deliberately. An optional auto-publish toggle activates them on import if they pass validation, which suits a repeatable promotion pipeline.
• Releases are local. Releases are immutable runtime snapshots local to each org.
• Test record is unset.
• Auto-email is disabled. Recipient / CC / from-address / template IDs are org-specific Lookup values and are scrubbed on export.

Name collisions

With a Duplicate conflict policy (or for a first-time import where no identity match exists), if the target org already has a template with the same name the import auto-renames to <Name> (Imported 1), then (Imported 2), and so on, and gives the copy its own fresh identity. The summary surfaces the rename so you can fix it from the Library. The same auto-rename runs on Create template when the requested name already exists: the new template lands as <Name> #<last 4 chars of Id> (e.g. Invoice #a1B2) and a “Template renamed” toast appears so authors immediately see what happened. Bundle display names are likewise unique, with auto-rename on insert and collision protection on update.

Starter templates

The Template Library’s right-rail help pane carries a Starter templates card linking to a gallery of six ready-to-import templates: Sales Proposal (Opportunity), Account Statement, Welcome Letter (Contact), Lead Follow-up, Case Summary, and Order Confirmation. All six are built on standard Sales and Service objects with no custom fields, so they import cleanly into any sandbox via the existing Import flow. The starters are built with current editor features - native table blocks with row-level repeats, merged title and total rows, three-column status strips, and an asymmetric letterhead layout - so a fresh download gives you enterprise-shaped output out of the box. Use them as a starting point or as worked examples of the features in this guide.

A localised interface

The Sliick Docs interface is presented across more than ten languages alongside English - German, Spanish, French, Italian, Japanese, Korean, Dutch, Portuguese (Brazil), Chinese (Simplified), and Chinese (Traditional) - covering the surfaces non-admin users see (the record-page generator, the help pane, and Flow error messages) as well as the wider application. Each user sees Sliick Docs in their own Salesforce language with no admin configuration.

Template content stays in whatever language the author writes it in; localisation applies to the surrounding application, not to the documents you design.

Security and trust

Sliick Docs is built to a Salesforce-first security model and has passed the AppExchange security review. The short version for a security or compliance reviewer:

• Your data never leaves Salesforce. PDF and Word documents are generated natively, inside your org. No external rendering service, no third-party endpoint, no Remote Site or Trusted Site is required.
• Your existing Salesforce permissions are enforced everywhere. Every read and write Sliick Docs performs runs with the user’s own sharing, profile, and field-level security. Two users will see only the data they’re already entitled to see, in the editor and in the generated documents.
• Published releases are frozen snapshots. Each Publish action creates an immutable release that the package treats as read-only: permission-set field-level security plus a write-guard trigger refuse edits and deletes through every Sliick path. A document generated today will look identical a year from now, even if the underlying template has been rewritten.
• Every generation is fully audited. Each file, single or bulk, is logged as a Generation with who ran it, when, in which format (PDF or Word), against which record, with which template release, the resulting file, and (when auto-email is on) every recipient address.
• Fingerprinted audit log for regulated industries. When per-template audit is enabled, every successful generation captures a fingerprint of the resolved merge values for integrity verification, written through a protected path so users cannot suppress or forge entries. (The fingerprint defends against accidental corruption and tampering by non-administrators. As with any in-org integrity scheme, a Salesforce System Administrator retains the platform-level ability to edit their own org’s data; layer Field History Tracking on the audit records if regulator-grade tamper evidence is a requirement.)
• Retention policies are enforceable. Per-template auto-delete windows are honoured by a nightly sweep; the Generation row survives as audit trail even after the file is gone.
• Least-privilege permission sets out of the box. Three permission sets ship with the package - Admin, User, and Automation - so end users only get the ability to generate, automation accounts only get what they need to run, and admin rights stay with a small group of template authors.
• Reviewed by Salesforce, not by us. Sliick Docs is listed on the AppExchange, which means an independent Salesforce security review has examined the package against the AppExchange Security Requirements before it was made available.

Detailed technical guarantees are available on request for security-review processes.

Troubleshooting and reference

Authoring

Batches

Imports

Runtime (end users)

Generated file naming

• Proof files: <Template Name> - v<Version Number> - Proof - <Record Id>.<ext> where <ext> is pdf or docx.
• Runtime files: the per-template File name pattern (with merge-field tokens like {{Account.Name}} - Summary.pdf), or the default {{<BaseObject>.Name}}.pdf if blank. The extension auto-swaps to .docx for Word output. Illegal filename characters are stripped automatically.

What is intentionally NOT in v2.1

• Standard, native rendering only: standard PDF and Word generation runs natively on the platform - by design, so nothing leaves your org. (The optional premium high-volume path handles large image-heavy documents.)
• Custom fonts: Arial, Times New Roman, Helvetica, and Courier New only (the fonts the native Salesforce PDF engine supports).
• Vertical cell merge (rowspan): horizontal cell merging only.
• Corner radius on blocks: the native PDF engine does not support rounded corners.
• Word output for Combined / Both batch modes: Word batches require Individual mode.
• Word output for templates with a text watermark or barcode block: the validator rejects it at save. Split into separate templates if both formats are needed. (Image watermarks are fine in both formats.)
• Per-template Word theme override on bundle Word output: bundle Word uses the org default theme; single-template Word honours per-template overrides.
• Native e-signature is in closed pilot, not general availability. Contact us to request access.

Premium high-volume rendering and bring-your-own cloud storage require Sliick Files; both are opt-in and do not change standard generation.

Further reading

• Sliick Docs product page
• Sliick Docs v2.1 release notes
• Sliick Files: bring-your-own cloud storage
• Contact the Sliick team