Data Set Dynamic Values
A linked control shows the user one field — the Display Field. The other fields of the selected record are not thrown away: they are captured with the answer and can be used anywhere else in the checklist.
That is what makes a Data Set a lookup rather than just a list. The user picks Northwind Traders, and the checklist fills in the account manager, the region and the renewal date on its own.
This page assumes you already know how Dynamic Values work in general. Everything here is an extension of that feature, not a separate one.
What Linking Changes
An ordinary Dropdown called Client contributes a single dynamic value, {{content.client}} — the selected option's text.
When that Dropdown is linked to a Data Set, that single value is replaced by one dynamic value per Data Set field:
| Dynamic value | Placeholder token |
|---|---|
| Client: Name | {{content.client.name}} |
| Client: Region | {{content.client.region}} |
| Client: Account Manager | {{content.client.account_manager}} |
| Client: Renewal Date | {{content.client.renewal_date}} |
The token is built from the control's label and the field name, both lower-cased with spaces replaced by underscores.
This applies to linked Dropdown, Multi-Choice and Sub-Tasks controls.
A linked Table keeps its plain {{content.<label>}} token instead — a table is many records at once, so there is no single record's field to resolve.
note
The list updates as soon as you save the link, without reloading the designer. Disconnect the control and the plain token comes back.
Using Them as Placeholders
Data Set dynamic values are inserted into Text and Mail-To controls exactly like any other — type {{ or click Insert Dynamic Value, and pick the field from underneath its control.
In the checklist they resolve live: as soon as the user chooses a record, every placeholder for that control fills in. Change the selection and they all change together.
Until something is selected, the placeholder shows its token so it is obvious that a value is expected rather than looking like a blank.
Multi-Select Sources
For Multi-Choice and Sub-Tasks the placeholder shows the field's value across every selected (or ticked) record, comma-separated:
Sites: London, Manchester, Leeds
Duplicates and blanks are removed, so a field that is the same on three selected records appears once.
For Sub-Tasks the values follow the ticked items and update each time one is ticked or unticked.
Using Them as Bindings
A Data Set field can also pre-fill another control. This is the "auto-fill" pattern: pick a client, and a Short Text control fills with the account manager, a Date control with the renewal date, an E-Mail control with the contact address.
- Select the control you want to fill (the target — not the linked control).
- Open its Settings cog and choose Bindings.
- Choose Dynamic Value as the binding type.
- In the picker, find the linked control and select the field beneath it.
- Click Save, then save the template.
The picker is three levels deep — task, then control, then Data Set field. The linked control itself is shown as a non-selectable heading; you always bind to one of its fields.
Which Fields Can Fill Which Controls
Each Data Set field type behaves like the equivalent control type, so the usual binding compatibility rules apply:
| Data Set field type | Can fill |
|---|---|
| Text, Number, True/False | Short Text, Long Text |
| Date | Short Text, Long Text, Date & Time |
| Short Text, Long Text, E-Mail | |
| URL | Short Text, Long Text, Website, Video, Embed |
Two further rules follow from the source control:
- A Dropdown source produces a single value, so it can fill any compatible control above.
- A Multi-Choice or Sub-Tasks source produces a comma-separated list, so it can only fill Short Text and Long Text. It is not offered for Date, E-Mail, Website, Video or Embed targets.
Anything incompatible is simply not listed in the picker.
How Bindings Behave in a Checklist
- The target control is filled the moment a record is selected, and re-filled whenever the selection changes.
- The value is saved like any other answer, and broadcast to everyone else viewing the checklist.
- The user can type over a filled value. As with any content binding, changing the source selection again will overwrite that edit.
- Blank fields produce a blank value — a record with no Region clears the control bound to Region.
A Worked Example
A Client Onboarding template with a Clients Data Set containing Name, Account Manager, Support Email and Renewal Date:
- Link a Dropdown labelled Client to the
ClientsData Set, with Name as the Display Field. - Bind a Short Text control labelled Account Manager to
Client: Account Manager. - Bind an E-Mail control to
Client: Support Email. - Bind a Date & Time control labelled Renewal Due to
Client: Renewal Date. - In a Mail-To control, put
{{content.client.support_email}}in To and{{content.client.name}}in the body.
The person running the checklist picks one client. Four other controls and the email fill themselves in, and nothing is mistyped.
Renaming Things
Placeholders and bindings track the control and the field themselves, not their names. Renaming the control or the field changes the token you would insert next time, but placeholders that are already in place keep resolving, and existing bindings keep working.
Deleting the field is different — a placeholder for a field that no longer exists resolves to nothing, and a binding to it stops filling anything. If you delete a field that is used as a Display Field or a Table column mapping, CheckFlow blocks the deletion; other fields can be deleted freely, so check Connections first.
Related Pages
- Dynamic Values — the general mechanism this extends.
- Using Data Sets in Checklists — where the record values come from.
- Fields — each field becomes its own dynamic value.