Document Templates

A Document Template is a Word-compatible file with placeholders that ApprovIQ fills in from project data when the document is generated. Templates are how you produce consistent project documents — certificates, approval letters, reports — without rewriting them for every project.

Templates are managed under Document Templates (/document-templates), accessible from Project Creation Setup.

Placeholders

ApprovIQ uses Word's standard merge fields as its placeholders. You insert them in the built-in document editor via the merge-field panel or Insert → Field → Merge Field. When the document is generated, each merge field is replaced with the corresponding value from the project. Word displays a merge field as its name wrapped in guillemets — so a field named ProjectName appears in the template as «ProjectName».

There are two kinds of placeholder:

Single-value placeholders

Insert a merge field whose name matches a project-wide value — for example, «ProjectName», «ProjectAddress», or «ProjectInformation_DAReference». ApprovIQ substitutes the value when the document is generated.

Repeating rows (TableStart / TableEnd)

To produce a table where one row is repeated once per item in a group — one row per relied-upon document, one row per approval item, and so on — use Word's mail-merge group convention:

1. Build the table and lay out the header row and one body row.
2. In the body row, at the beginning of the leftmost cell, insert a merge field named TableStart:<GroupName>.
3. In the same body row, at the end of the rightmost cell, insert a merge field named TableEnd:<GroupName>.
4. In the cells in between, insert the per-row placeholders — for example «document_name», «Purpose», «uploaded_at».

<GroupName> is the name of the data source — e.g. DocumentSet_ReliedUponDocuments, ApprovalItems, Documents, Comments. The placement matters: TableStart must sit at the start of the leftmost cell and TableEnd must sit at the end of the rightmost cell, because Word treats everything between them as the repeating region. When the document is generated, the whole body row is copied once per item in the group and each per-row placeholder is filled in with that item's values.

The same pattern works for any table or paragraph repetition; this is standard Word mail merge. See Syncfusion's Mail merge for a group reference for the underlying behaviour.

tip

If you need more than one column in the table, place your per-row merge fields in the middle cells. TableStart and TableEnd must stay anchored at the beginning of the leftmost cell and the end of the rightmost cell respectively — otherwise Word won't repeat the whole row.

What data is available

When ApprovIQ renders a template for a project, it exposes both project-wide values (for single placeholders) and grouped lists (for repeating blocks):

Built-in project fields

These project-wide values are always available, no configuration required:

• {{ProjectName}} — the project's name
• {{ProjectAddress}} — the project's address

Project information fields (project-level)

Every project information field that is not linked to a document set — i.e. project-level fields — is available as a project-wide value. ApprovIQ makes each value available under four placeholder names so you can use whichever form reads best:

• {{ProjectInformation_<name>}} — prefixed, field name as-entered (spaces preserved)
• {{ProjectInformation_<nameSpaceless>}} — prefixed, spaces stripped
• {{<name>}} — bare, field name as-entered
• {{<nameSpaceless>}} — bare, spaces stripped

So a field named DA Reference is available as {{ProjectInformation_DA Reference}}, {{ProjectInformation_DAReference}}, {{DA Reference}}, and {{DAReference}} — they all produce the same value. The spaceless, prefixed form is the safest to use in practice because Word sometimes dislikes spaces and colons inside placeholder names.

Per-document project information fields (fields linked to a document set) are not available as project-wide values. They only appear inside a document set's repeating block — see DocumentSet_<SetName> below.

ApprovalItems — the approval list

Each approval item carries:

• title, description, item_number, status_label, review_sequence, item_type
• document_count, latest_document
• A nested Documents and Comments group covering the documents and comments attached to that item

Documents — every active project document

Each document entry carries:

• original_filename
• status_label (Accepted, Stamped, Marked Up, No status, …)
• notes, uploaded_at, file_size, is_latest
• item_title, item_number (the approval list item the document was uploaded against, if any)

Comments — every project comment

Each comment entry carries:

• content, user_name, author_role, created_at
• item_title, item_number

DocumentSet_<SetName> — one group per document set

For each document set in the project that has at least one project information field linked to it, ApprovIQ builds a repeating group named DocumentSet_<SetName>. Spaces in the set's name are removed: a set named Relied Upon Documents becomes DocumentSet_ReliedUponDocuments.

note

A document set only appears as a repeating group if at least one project information field is linked to it. A document set with no linked fields has no per-document columns to render, so ApprovIQ omits it from the template data. Link at least one field if you want to iterate over the set.

Each entry in the group carries:

• document_name and original_filename
• status_label
• notes, uploaded_at, file_size, is_latest
• item_title, item_number
• Every linked field's value, under the field's name with spaces removed

So a field named Purpose linked to Relied Upon Documents is available as the merge field «Purpose» inside a body row wrapped with «TableStart:DocumentSet_ReliedUponDocuments» and «TableEnd:DocumentSet_ReliedUponDocuments». Every document in the set gets its own row with its own Purpose value. This is the most important thing to understand about per-document project information fields: they only come to life inside the TableStart / TableEnd region of the document set they're linked to.

How project information fields and document sets flow in

It's worth stating the pattern plainly, because the two flavours of project information field behave differently inside a template:

What you want in the template	Where to configure it	How it renders
A single project-level value (e.g. DA Reference, Building Class)	A project information field with no document-set binding	Project-wide merge field: «ProjectInformation_DAReference»
A list of received documents (e.g. a table of relied-upon documents)	A document set, plus at least one project information field linked to it	Table body row wrapped with «TableStart:DocumentSet_ReliedUponDocuments» … «TableEnd:DocumentSet_ReliedUponDocuments»
A column in that list with its own per-document value (e.g. Purpose per document)	A project information field linked to the document set	A per-row merge field inside the wrapped row, by field name: «Purpose»
The project's name or address	Built in — nothing to configure	«ProjectName», «ProjectAddress»

Example: a list of documents with purposes

To produce a table where each row lists a relied-upon document and its purpose:

1. Insert a table with a header row and one body row. Use three columns: Document, Purpose, Received.
2. Click into the leftmost body cell and, at the very beginning of it, insert a merge field named TableStart:DocumentSet_ReliedUponDocuments. Then in the same cell add the per-row field document_name.
3. In the middle cell, insert Purpose.
4. Click into the rightmost body cell and insert uploaded_at, then at the very end of the cell add a merge field named TableEnd:DocumentSet_ReliedUponDocuments.

The body row now looks roughly like this:

«TableStart:DocumentSet_ReliedUponDocuments»« document_name »	«Purpose»	«uploaded_at»«TableEnd:DocumentSet_ReliedUponDocuments»

When the document is generated, the row is repeated once per document in the "Relied Upon Documents" set, each with its own document_name, Purpose, and uploaded_at.

See Generating a Project Document from Relied-Upon Documents for the end-to-end setup including the document set, linked field, and project type configuration required.

Editing templates

Templates are edited in a built-in, in-browser document editor. Changes are autosaved — wait for the "Saved" indicator before closing the tab. Templates, like everything in Project Creation Setup, are snapshotted into projects at generation time; editing a template never retroactively changes documents already generated from an older version.

Who can edit templates and generate project documents

Editing templates and generating project documents from them are available only to approvers and co-approvers of the project. Applicants and collaborators see generated project documents once they are produced but cannot edit templates or trigger generation.

Related

• Generating a Project Document from Relied-Upon Documents
• Project Information Fields
• Document Sets