Using Data Sets in Checklists

This page explains what the person running a checklist actually sees when a control is linked to a Data Set, and what happens when the Data Set changes underneath them.

Everything here applies equally to checklists run by your team and to checklists opened through a public share link.

Dropdown and Multi-Choice

Linked Dropdown and Multi-Choice controls fetch their options from the linked View every time the checklist is loaded. They always reflect the current state of the Data Set.

  • Each option's label is the record's Display Field value.
  • If the View returns more than 20 records, the control gains a search box so long lists stay usable.
  • If the View returns no records, the control shows "No options available. Contact your administrator."

Selecting an option behaves like any other Dropdown or Multi-Choice answer — it is saved immediately, it satisfies a Required control, and it broadcasts to anyone else who has the checklist open.

Adding Options Mid-Run

Because options are read live, adding a record to the Data Set makes it selectable in checklists that are already open — no template change and no checklist update required. This is one of the main reasons to use a Data Set rather than a hand-typed list.

The same applies in reverse: removing a record, or narrowing the View's filter, removes the option from checklists that are still running.

Sub-Tasks

A linked Sub-Tasks control is populated once, when the checklist is created. One sub-task is created per record in the View, labelled with the record's Display Field value.

Later changes to the Data Set do not alter existing checklists. A checklist created in March keeps the March list of sub-tasks, which is usually what you want for an auditable record of what was actually checked.

Table

A linked Table control is also populated when the checklist is created:

  • The table gets a header row plus one row per record in the View.
  • Mapped columns are filled from the Data Set and are read-only; their headers are the Data Set field names.
  • Unmapped columns are empty and editable, for the person running the checklist to fill in.
  • If Allow Add/Remove Rows was enabled on the control in the template, that still applies — users can add extra rows, which are fully editable.

This makes a linked Table a natural fit for "one row per site / per asset / per employee" checks, where the reference data is known and the results are not.

Answers Are Snapshots

When a user selects a record, CheckFlow stores three things with the answer:

  1. The record's ID
  2. The text that was displayed at the time
  3. A snapshot of every field value on that record at the time

This means an answer is a permanent record of what was chosen and what it meant at that moment. Editing the record, renaming it, changing the link's Display Field, deleting the record, deleting the View, or deleting the entire Data Set will never rewrite an answer that has already been given.

The same applies to Sub-Tasks items and Table rows, which each keep the snapshot of the record they came from.

Options That Have Disappeared

If a checklist is still open and the record that was previously selected is no longer in the View — because it was deleted, or because the View's filter no longer matches it — the control still shows the stored answer, with (deleted) appended:

Northwind Traders (deleted)

The answer is preserved and the checklist can still be completed. The suffix tells the user that the option is no longer offered, so they can pick a current one if that is appropriate.

Required Validation

Required works on linked controls exactly as it does on manual ones — the task cannot be completed until a record has been selected (Dropdown, Multi-Choice) or all sub-tasks are ticked (Sub-Tasks).

The Required checkbox stays editable in the template after a control is linked, so you can change it at any time.

Real-Time Collaboration

When several people have the same checklist open, a selection made on a linked control is broadcast to everyone immediately, just like any other answer.

One deliberate detail: dynamic value bindings driven by the selection are applied on the machine where the selection was made, and are broadcast from there as ordinary control values. They are not re-applied in every other open browser, which would otherwise cause the same update to be written many times over.

What Happens When the Template Is Updated

If you update an open checklist to a newer template version, CheckFlow does its best to carry existing answers across, including across changes to the link:

ChangeWhat happens to the answer
The link is unchanged (same Data Set and View)The answer is carried over exactly as it was, including its snapshot.
The control is newly linked, or re-pointed at a different ViewCheckFlow re-matches the previous answer to a record in the new View by its display text. A match becomes a proper linked answer; anything that cannot be matched is reported.
The link is removedThe previously selected record's text is matched against the control's new manual items.
Sub-Tasks, same Data Set and ViewItems are refreshed from the View and the ticked state is re-applied by record — records that have gone drop off, and newly added records start unticked.
Sub-Tasks, link added, changed or removedThe ticked state is re-applied by matching the sub-task text.

Values that could not be matched are reported to you as part of the update, so you know where a checklist needs attention.

note

Because a linked answer is a point-in-time snapshot, it is never silently re-resolved. If the link now displays a different field, existing answers continue to show the text that was recorded when they were given.

Related Pages