Use Conditional Logic with Related Lists in Dochly
How related lists and conditions interact
In a Dochly template, a related list section is bound to a Salesforce related list on the primary object — for example, Opportunity Products on an Opportunity, Contacts on an Account, or Tasks on a Case. Conditional logic interacts with a related list section at exactly one level: the section as a whole.
A section-level condition uses parent object fields and controls whether the entire related list section — heading, table, and all rows — appears in the document at all. There is no separate child-level or row-level condition: once a related list section is shown, its table always renders one row for every record currently in that related list, using the fixed columns configured for the table. The two things people often expect — filtering which rows show, and hiding a column conditionally — are not available inside the table.
Field scope for the section condition
A related list section's show/hide condition is applied to the container that wraps the entire related list — the heading, the table, and every row it will ever render. Because the condition is evaluated once, before the table renders any rows, it can only use fields from the parent object — the record the document is being generated from.
Any field on the parent object, including formula fields — for example, show the Products section only when Opportunity.Has_Products__c is true. This is the same field scope used for showing or hiding any other section of the document.
There is no row-level condition on a related list table, so fields on the child object (like OpportunityLineItem.Quantity) can't be used to decide whether an individual row appears. The section condition either shows the whole table or hides it — it has no visibility into the rows it will render.
To reference a grandparent field in the section condition — for example an Account field when the section lives on an Opportunity — create a formula field on the parent object (Opportunity) that copies the grandparent value, e.g. a formula that copies Account.Type onto the Opportunity. The section condition then references that formula field directly, since it only ever evaluates against the parent object.
What you can and can't control
There's exactly one supported way to apply conditional logic to a related list, and several things people commonly expect that aren't available. Here's the full picture:
Show/hide the whole list section
Apply a show/hide condition to the entire related list section — heading, table, and all rows together — using a field on the parent object. Covered in detail below.
Filtering which rows appear
The table has no per-row condition. Once a related list section is shown, every record in the related list appears as a row — there's no way to include only the records that meet a condition.
Splitting one list into labelled groups
A single related list table can't be split into sub-groups (like "Products" and "Services") by condition. Presenting genuinely separate groups requires genuinely separate related lists in Salesforce.
Column, cell, and totals logic
There's no way to hide a column conditionally, branch a cell's content with if/else, or add a conditional totals/summary row inside the table.
Why you can't filter individual rows
The related list table reads the connected related list at generation time and renders one row for every record it finds. There's no condition you can attach to the repeating row itself — the row isn't a separate element with its own visibility setting, it's just the table's fixed template repeated once per record.
In practice this means an inactive product, a zero-quantity line, or a record that's only relevant internally will appear on the document exactly the same as any other record in that related list, in the same columns. The table can't tell them apart.
Lists every record currently in the connected related list, one row per record, using the fixed columns you configured for the table.
Skip a record because a field value doesn't match a condition. There is no per-row show/hide, and no visual condition builder attached to a row.
If certain records genuinely shouldn't reach the document, they need to be kept out of the related list itself in Salesforce — see Controlling records via Salesforce below.
Grouping isn't supported inside one list
A related list table can't split its own related list into labelled sub-groups — there's no condition that routes some rows from Opportunity Products into a "Products" group and others into a "Services" group within the same table. The table has one job: list every record from the one related list it's connected to, in one set of columns.
If Products and Services genuinely need to appear as two separate, independently labelled sections, that's only possible when they are two separate related lists in Salesforce — for example, Opportunity Products and a separate custom Services junction object. Each one gets its own related list table in the template, and each table still always lists every record from its own related list.
Each of the two tables above can still use a section-level show/hide condition — for example, hiding the Services table entirely when the Opportunity has no related Service records, using a parent formula field such as Has_Services__c. See Show or hide the entire related list section below. What isn't possible is deriving two labelled groups from a single related list using a condition.
Show or hide the entire related list section
Apply a section-level show/hide condition to control whether the entire related list block — heading, table, and all rows — appears in the document. Section-level conditions use parent object fields.
Select the related list container in the editor
Click the section heading or the outer container that wraps the entire related list block — not an individual row inside it. In the template editor, related list sections are typically wrapped in a named section block. Click the section name or the wrapper element to select the entire container.
Add a condition using a parent object field
With the section container selected, open Conditional Logic → Add Condition. Use a parent object field — e.g. Has_Services__c is true (a checkbox formula on the Opportunity that's true when any service line exists). Set Action to Show when condition is true.
Result: section appears only when relevant
When the condition is false, the entire section — heading, table, all rows — is invisible in the generated document. When true, the section appears and its table lists every record from the connected related list, in the fixed columns configured for that table. The show/hide condition is the only lever on the section; it doesn't do anything to individual rows once the section is visible.
// Section visibility only — no row-level logic exists
// Section condition (parent field): Has_Services__c == true
// If Has_Services__c is false:
// (the entire PROFESSIONAL SERVICES section is invisible)
// If Has_Services__c is true, the section renders in full —
// every record in the connected Services related list appears
// as a row, in the table's fixed columns:
PROFESSIONAL SERVICES
Implementation | £2,400
Training workshop | £800
(— any other record in the Services related list also appears —)
Columns, cells, and totals
Beyond row filtering, three other things people commonly ask for inside a related list table also aren't supported, for the same underlying reason — the table has no per-row or per-cell logic, only a fixed layout applied uniformly to every record:
The set of columns is fixed when the table is built and applies to every row and every generated document. A column can't be hidden for records where it doesn't apply — see Dynamic tables for the full explanation.
Each cell displays the single field it's mapped to. There's no branching logic inside a cell — it can't show one thing for some rows and something else for others based on that row's data.
Conditional totals: the table doesn't calculate or conditionally display totals, subtotals, or a summary row. If a document needs a total, calculate it in Salesforce (a rollup summary or formula field on the parent record) and place it as a regular merge field below the table — that surrounding text can use a section-level show/hide or if/else condition, but the total itself is never computed inside the table.
Controlling which records appear, via Salesforce
Since the table itself can't filter, hide, or group individual records, the only reliable way to control which records show up in a related list section is to control which records exist in that related list in Salesforce, before the document is generated.
Remove or reassign records that shouldn't appear
If a specific line item, contact, or task genuinely shouldn't be on the document, delete it, reassign it off the related record, or move it so it's no longer part of that related list. The table can only reflect what's actually there.
Use record ownership and sharing rules
Where records are shared conditionally (for example, which Contacts or Tasks a given user or process can see), Salesforce ownership and sharing rules determine what ends up in the related list that Dochly reads — the document template has no separate filtering layer on top of that.
Use a different, purpose-built related list
If only a subset of records should ever reach this document, consider a dedicated child relationship or junction object that only contains the relevant records, and connect the table to that related list instead of a broader one that contains records you don't want to show.
None of this happens inside the document template — it's standard Salesforce record and sharing management. Once the related list contains the right records, the table will display exactly those records, in full, every time.
Pattern library
Common, supported ways to use conditional logic around a related list. None of these rely on row, group, or count-based filtering inside the table — they work because the section-level condition controls visibility, and the underlying related list already contains the right records.
Show a Services section only when there are services on the deal
Connect one table to the Opportunity Products related list (always shown) and a second table to a separate Services related list. Apply a section-level show/hide to the Services table using a parent formula field such as Has_Services__c, so it disappears entirely when the Opportunity has no related Service records.
Show or hide an Opportunities section based on the Account
Apply a section-level condition to the Opportunities related list section using a parent (Account) field — for example, only show it when Account.Type == "Customer". Every Opportunity currently related to the Account will appear once the section is visible; there's no way to show only open ones within that same table.
Show a Tasks section only when the Case has related tasks
Apply a section-level show/hide to the Tasks related list section using a parent formula field such as Has_Tasks__c, computed from a rollup on the Case. If you need only open tasks to reach the document at all, keep the Tasks related list itself limited to open tasks in Salesforce — the table will then show whatever is left.
Show a note that depends on the Opportunity, not the line items
Compute a rollup or formula field on the Opportunity (for example, total line item count) and use it in an if/else condition elsewhere in the document — see Use if/else conditions. That condition can control a paragraph near the table, but it can't reach inside the table to change which rows or columns appear.
Frequently asked questions
Account.Type), then reference that formula field in the section condition. The condition itself only ever evaluates against the object the related list section lives on.You now know exactly what conditional logic can do around a related list: show or hide the entire section based on a parent field — and nothing more granular than that inside the table itself. Final guide in this series: Conditional logic troubleshooting — common errors and fixes in Dochly — diagnose and fix every conditional logic issue including conditions that never fire, wrong field scope, and syntax errors.
Not on AppExchange yet — contact us and we'll set you up