Create Dynamic Tables with Conditional Logic in Dochly

A table in a Dochly template is bound to a Salesforce related list (for example, Opportunity Line Items on an Opportunity, or Contacts on an Account). When a document is generated, Dochly repeats the table's data row once for every record in that related list, filling in the merge fields you've mapped to each column.

The table is flat: every record in the related list becomes a row, and every configured column appears on every row. There is no per-row condition, no per-cell logic, and no way to conditionally hide a column — the table simply reflects whatever is in the related list, laid out in the columns you set up.

Every table in a Dochly template is connected to a related list on the record being generated — for example, Opportunity Line Items on an Opportunity, or Contacts on an Account. You choose the related list once when you build the table, then map each column to a field on those related records.

When the document generates, Dochly reads every record currently in that related list and renders one row per record, in the column layout you defined. There's no row-by-row decision-making — if a record is in the related list, it appears as a row.

This example adds a line item table to a quote template, listing every Opportunity Product on the Opportunity being generated.

The set of columns in a table is defined once, when you build the table, and it does not change based on the data in any particular record. Every column you add appears in every generated document that uses that template — whether or not a given row has meaningful data for that column.

There is no option to hide a column when it isn't relevant to a specific deal, customer, or record type. If a column has nothing to show for a row, the cell simply renders blank (or shows the field's default value) rather than the column disappearing.

Each cell in a table row displays the value of the single field it's mapped to for that row — nothing more. There is no if/else logic inside a table cell, so a cell can't switch between two different pieces of content (for example, showing a price for one line type and the word "Included" for another) based on other data in the row.

Formatters that transform a single value — such as displaying a number as currency, or a date in a particular format — are supported on a cell's mapped field. What isn't supported is branching logic that changes which field, or which wording, appears based on a condition.

If the related list connected to a table has no records at all, the table still renders its header row, with no data rows beneath it. There is no built-in "no records" message, no variable that reports the row count, and no way to conditionally hide the whole table when it would otherwise be empty.

The table element doesn't calculate or conditionally display totals, subtotals, discount lines, or tax lines — it only lists rows from the related list in fixed columns. There's no aggregate function inside the table and no way to add a summary row that appears or changes based on a condition.

If a document needs a total, subtotal, or tax figure, calculate it in Salesforce — for example with a rollup summary field or a formula field on the parent record — and place that value as a regular merge field in the document, outside the table structure. Whether that merge field (or the paragraph containing it) appears at all can be controlled with a section-level show/hide condition or if/else logic — see Show or hide sections and Use if/else conditions — but that logic applies to a block of content next to the table, not to a row inside it.

Common, supported ways to use the table element. None of these rely on row, column, or cell conditions — they work because the underlying related list already contains the right records and fields.