Data Sets: Stop Retyping Your Reference Data Into Every Checklist

A site closes. Somebody updates the list of offices in the template they remember, and leaves it alone in the eleven they don't. Three months later a checklist is still offering an office that no longer exists, and the answers it captures are quietly wrong. Nobody did anything careless. The list simply lived in twelve places, and a list that lives in twelve places goes stale in eleven of them.

The hard-coded dropdown is the original sin of checklist tools. The client list is typed into the onboarding template. And the quarterly review template. And the offboarding template. Each is a separate copy, entered by hand, and none of them knows the others exist. Adding a client means opening every template and adding the option again. Worse, the option is only ever text: when someone picks the client, they then type the account manager, the region and the renewal date into the next three fields — every time the checklist runs — even though all of that already exists somewhere.

Data Sets make a list change a data change instead of a template change. A Data Set is a reusable table of reference data that lives in your Library. Link it to a control and the control reads the current list every time a checklist loads; pick a record and its other fields can fill in the rest of the checklist on their own. This guide covers building the table, importing it from a spreadsheet, filtering it with Views, linking it to the four controls that support it, what happens to answers when the data changes, the built-in System Data Sets, eight ways teams use them, and how to keep a Data Set in step with the system that owns the data.

What a Data Set Is

Six terms carry the whole feature, and they are worth fixing before going further.

Four controls can be linked. A Dropdown lists one option per record and the user picks one. A Multi-Choice lists one option per record and the user picks any number. A Sub-Tasks control gets one sub-task per record, created with the checklist. A Table gets one row per record, with the columns you map to a field filled in and read-only, and the rest left editable for the person running the checklist.

Build the Table

Data Sets are created from the Library. You need to be an Administrator or hold the Library.Creator permission, and the folder you create the Data Set in decides who can see and edit it.

The six field types behave the way you would hope. Number fields sort numerically rather than alphabetically. Date fields accept 2026-03-14 or a full date and time, and sort chronologically. Email must be a valid address; URL must be an absolute http or https address. True/False accepts true, false, yes, no, 1 and 0 on the way in and stores them all as true or false. An empty cell is always allowed, whatever the type — types only constrain values that are actually entered.

Renaming a field is always safe, because links, Views, dynamic values and stored answers all reference the field by its internal ID rather than its name. Changing a field's type is checked first: if any existing value would be invalid under the new type, the change is rejected until you clear or correct those cells. Changing to Text always succeeds. Deleting a field deletes its values in every record and cannot be undone, and is blocked while the field is in use as a Display Field or in a Table column mapping.

Import From a Spreadsheet

If the list already exists in a spreadsheet, save it as CSV and attach it when you create the Data Set. CheckFlow reads the first row as the field names, detects each column's type from its values, and creates one record per remaining row. If you leave the name blank, the file name is used.

One consequence to know: Number is checked before True/False, so a column containing only 1 and 0 becomes a Number field. If a column is detected as the wrong type, change it afterwards from the column header menu; changing to Text always works. The CSV follows the standard conventions — commas, double quotes around values containing commas or line breaks, doubled quotes for a literal quote — and the limits are a 5 MB file, 50 columns and 10,000 rows, with 5 KB of cell text per record. Nothing is imported unless the whole file is valid; a rejected import leaves the Data Set exactly as it was, and the error messages name the row.

Refreshing an existing Data Set

Import CSV (Replace) in the Data Set toolbar swaps the entire contents of an existing Data Set for the contents of a CSV file. It is the usual way to refresh reference data that is maintained somewhere else. Columns are matched to existing fields by name, so links, Views and dynamic values that reference those fields keep working; any column that does not match an existing field is added as a new one; fields not present in the file are kept and left empty; and all previous records are removed. The replace runs as a single transaction, so a failure part-way leaves the Data Set untouched rather than half-empty.

Export goes the other way: it downloads the currently selected View as a CSV file, containing only the View's visible columns in field order and only the records that pass its filters, in its sort order, encoded so that accented and non-Latin characters open correctly in Excel. A small detail worth knowing: a cell whose value starts with =, +, - or @ would be read as a formula by a spreadsheet, so CheckFlow prefixes such values with a quote on export and strips it again on import. The round trip is lossless and nobody's spreadsheet runs a formula it did not expect.

Views: One Table, Many Lists

Views are what make a single Data Set reusable across many templates. One Clients Data Set can feed a control that offers Active Clients Only, another that offers Clients in EMEA, and a third that offers everything — without duplicating any data. Every Data Set can have up to 20 Views, and a control is always linked to a specific View, never to the table as a whole.

Each View has a tab above the grid; click a tab to apply it, and the + tab creates a new one. Click View Config to edit the current View's name, filters, sorts and column visibility. Filters are rows of a field, an operator and a value, combined with AND, so a record has to satisfy every filter to appear:

Sorts apply top to bottom, the first as the primary sort and each later one breaking ties. Column visibility hides a field from the View and from its CSV export — but not from dynamic values or from the record snapshot stored with an answer, which is why hiding a column is a presentation choice rather than a security boundary. A filter or sort on a field that has since been deleted is quietly ignored rather than breaking the View.

The All Records View cannot be renamed or deleted, though it can carry filters and sorts if you want. Deleting any other View is allowed even when template controls are linked to it; the templates show a warning banner until an author re-points or removes the affected controls, and checklists already running are unaffected. The Connections button in the Data Set toolbar lists every linked control with its template, version, control type and View, so check it before deleting a View, a field or the whole Data Set.

Link It to a Control

Linking is done in the Template Designer, so it needs template rights — Template.Creator or Administrator — rather than Library edit rights. You can link to any Data Set you can see in the Library; view access is enough, and a Data Set in a folder you cannot see simply does not appear in the dialog.

Links are stored against the template version they were created in. That is deliberate: changing or removing a link only affects checklists created from that point on, and checklists created from an earlier version keep running against the configuration they were created with. To remove a link, switch the source back to Manual list or click Disconnect; the control reverts to a manual control with whatever items it had before, which for a newly linked control is usually none, so rebuild the list before saving.

Because a Data Set can change independently of the templates that use it, the designer checks every link when you open a template and again when you save. A deleted Data Set, View or Display Field, a Table column mapped to a deleted field, or a linked Table whose View has grown past 500 records all produce a line under Some Data Set links need attention, and the save is blocked until each affected control is re-pointed or disconnected. Running checklists carry on working the whole time, because their answers are snapshots.

Live Options vs Snapshots

This distinction matters more than anything else on the page, so here it is on its own.

Dropdown and Multi-Choice controls fetch their options from the View every time the checklist is loaded. They always reflect the current state of the Data Set. Adding a record makes it selectable in checklists that are already open — no template change, no checklist update. Removing a record, or narrowing the View's filter, removes the option from checklists still running. If the View returns more than 20 records the control gains a search box so long lists stay usable; if it returns none, the control says "No options available. Contact your administrator."

Sub-Tasks and Table controls are populated once, when the checklist is created. One sub-task, or one table row, per record in the View at that moment. 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.

Whatever the user selects is stored as a snapshot. When someone picks a record, the checklist stores the record's ID, the text that was displayed, and every field value on that record at that moment. Editing the record, renaming it, changing the Display Field, deleting the record, deleting the View or deleting the whole Data Set will never rewrite an answer that has already been given. If a checklist is still open and the selected record is no longer in the View, the control still shows the stored answer with "(deleted)" appended — Northwind Traders (deleted) — so the person can see the option is no longer offered without losing what was recorded.

Updating an open checklist to a newer template version does its best to carry linked answers across. Where the link is unchanged the answer moves exactly as it was, snapshot included. Where the control is newly linked or re-pointed at a different View, the previous answer is re-matched to a record by its display text, and anything that cannot be matched is reported to you as part of the update.

Pick a Record, Fill the Checklist

A linked control shows the user one 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.

An ordinary Dropdown called Client contributes a single dynamic value, {{content.client}} — the selected option's text. Link that Dropdown to a Clients Data Set and the single value is replaced by one dynamic value per field:

The token is built from the control's label and the field name, lower-cased with spaces replaced by underscores. There are two ways to use them.

As placeholders

Insert a Data Set dynamic value into a Text or Mail-To control exactly like any other — type {{ or click Insert Dynamic Value and pick the field from beneath its control. In the checklist they resolve live: as soon as the user chooses a record, every placeholder for that control fills in, and changing the selection changes them all together. Until something is selected, the placeholder shows its token so it is obvious a value is expected. For Multi-Choice and Sub-Tasks sources the placeholder shows the field's value across every selected or ticked record, comma-separated, with duplicates and blanks removed: Sites: London, Manchester, Leeds.

As bindings

A Data Set field can also pre-fill another control. Select the control you want to fill — the target, not the linked control — open its Settings cog, choose Bindings, choose Dynamic Value, and in the picker find the linked control and select the field beneath it. The picker is three levels deep — task, control, field — and the linked control itself is a heading you cannot select; you always bind to one of its fields. Each field type behaves like the equivalent control type, so the usual compatibility rules apply:

A Dropdown source produces a single value and can fill any compatible control. A Multi-Choice or Sub-Tasks source produces a comma-separated list, so it can only fill Short Text and Long Text. Anything incompatible is simply not offered. In the checklist, the target is filled the moment a record is selected and re-filled whenever the selection changes; the user can type over a filled value, though changing the selection again overwrites the edit; and a blank field produces a blank value, so a record with no Region clears the control bound to Region.

Here is the whole thing end to end. A Client Onboarding template has a Dropdown labelled Client, linked to a Clients Data Set with Name as the Display Field. Bind a Short Text control labelled Account Manager to Client: Account Manager, an E-Mail control to Client: Support Email, and a Date & Time control labelled Renewal Due to Client: Renewal Date. In the welcome-email Mail-To control, put {{content.client.support_email}} in To and {{content.client.name}} in the body. The person running the checklist picks Northwind Traders. Four other controls and the email fill themselves in, and nothing is mistyped, because nothing was typed.

Conditional Logic on Linked Controls

Conditional logic works on linked Dropdown and Multi-Choice controls exactly as it does on manual ones. When you build a rule, the value list is populated from the linked View's records using the Display Field, sorted alphabetically. Rules are stored against the record rather than against the text that is displayed, so a rule keeps working if the record is later renamed or the Display Field is changed to a different column. Pick a vendor whose risk tier is High and the enhanced due-diligence tasks appear; pick a site in a different country and the local compliance section shows — all driven by data someone else maintains.

System Data Sets

CheckFlow ships with ten System Data Sets — common reference lists that are ready to use without you building or maintaining them. They behave exactly like your own when you link a control, with two differences: they are read-only for everyone including Administrators, and they do not appear in the Library. They are offered only where they are used, under a System group in the Link to Data Set dialog, and they do not count toward the limit of 100 Data Sets per team.

Link a Dropdown to Countries with Name as the Display Field and you have a country picker; bind another control to the ISO2 Code field and the two-letter code is captured alongside the name without anyone knowing it. If you need a restricted version — only the fifteen countries you operate in — create a small Data Set of your own containing exactly those rows, because you cannot add a filtered View to a System Data Set.

Eight Scenarios

Any list that more than one checklist needs to pick from belongs in a Data Set. Here are eight, each with the table, the View, the linked control and what the record fills in.

1. Client onboarding

Data Set: Clients — Name, Account Manager, Support Email, Region, Renewal Date, Active (True/False). View: Active Clients. Control: a Dropdown called Client on the first task. Fills: Account Manager into a Short Text, Support Email into an E-Mail control, Renewal Date into a Date & Time that anchors the renewal reminder task's dynamic due date. When a client churns, tick Active off and they vanish from every onboarding, review and offboarding dropdown at once.

2. MSP site visits

Data Set: Client Sites — Site, Client, Address, Site Contact, Contact Phone, Access Notes. View: one per client, filtered on the Client field, so each client's templates see only their own sites. Control: a Dropdown called Site. Fills: the address and contact into Text placeholders in the visit brief. Keep the alarm code out of it: hidden columns are still captured in the snapshot, so anything genuinely secret should not be in a Data Set that a widely shared template reads.

3. Asset audits

Data Set: Equipment — Asset Tag, Description, Location, Owner, Last Serviced. View: Server Room A, filtered on Location and under 500 rows. Control: a linked Table with Asset Tag, Description and Owner mapped and read-only, and a user-entered Condition column. Every audit checklist starts with one row per asset already filled in; the auditor only types what they found. The table is a snapshot of the View at creation, so last quarter's audit still lists last quarter's assets.

4. Vendor due diligence

Data Set: Vendors — Name, Category, Risk Tier, Contract Owner, Contract End. View: Active Vendors. Control: a Dropdown called Vendor. Fills: Contract Owner into a Short Text, Contract End into a Date. Rule: conditional logic shows the enhanced due-diligence section when the selected vendor's record is one with Risk Tier High — stored against the record, so renaming the tier label does not break it.

5. HR onboarding by role

Data Set: Job Roles — Role, Department, Line Manager Email, Equipment Bundle, Required Training. Control: a Dropdown called Role. Fills: Line Manager Email into the Mail-To that sends the first-day welcome, Equipment Bundle into the IT provisioning task's text, Required Training into a placeholder in the learning task. HR maintains one table; the onboarding template never changes when a role is added.

6. Property inspections, room by room

Data Set: Rooms — Property, Room, Floor, Inspection Points. View: one per property. Control: a linked Sub-Tasks control, one sub-task per room, created with the checklist. The inspector ticks off every room; the checklist cannot complete until all are ticked; and the March inspection keeps the March room list even if a room is added in April.

7. Software licence renewals

Data Set: Licences — Product, Vendor, Seats, Renewal Date, Owner Email. View: Renewing This Quarter, filtered on Renewal Date with the >= and < operators. Control: a Dropdown in a Licence Renewal Review template. Fills: Renewal Date into a Date control that anchors the "decide by" task's due date, Owner Email into the Mail-To that asks the owner whether to renew.

8. Country-specific compliance

Data Set: the System Countries set. Control: a Dropdown called Country with Name as the Display Field. Fills: ISO2 Code into a Short Text that your export, your webhook consumer or your reporting reads. No table to build, no list to maintain, and the answer carries the standard code alongside the human-readable name.

Keep It in Sync: API and Webhooks

If your reference data lives in another system — a CRM, an asset register, an HR platform — the Data Set should follow it rather than be maintained by hand. Data Sets are fully available through the CheckFlow REST API: you can create Data Sets, add and reorder fields (the API is the only way to reorder them), add, update and delete records, manage Views, and import or export CSV. A bulk records endpoint appends or replaces every record in a single call, in batches of up to 1,000, and a CSV import through the API is synchronous, so the response comes back once the import has completed. System Data Sets are returned alongside your own with a stable slug such as system-countries that works anywhere an ID does, and any write to one is refused.

Changes can also flow the other way. Three webhook events fire on record changes made through the API or in the web grid:

• data_set.record.created — a record is added, with its values.
• data_set.record.updated — only the fields that actually changed, with their previous and new values.
• data_set.record.deleted — the record's ID.

All three are team-wide, so filter on the Data Set ID in your handler if you only care about one table. Through Zapier the same events reach several thousand other services without any code.

Two things to know about API access. The Data Sets API authenticates with a team API key rather than a user account, so it is not subject to Library folder permissions; treat a key as full access to every Data Set in the team. And the developer documentation, including the exact endpoints and payloads, lives on the developer page.

What a Data Set Is Not

Two expectations are worth heading off, because both are reasonable and both are wrong.

A Data Set is not a database that checklists write to. Data flows one way: Data Set to checklist. Picking a record stores a snapshot on the checklist and never writes anything back to the Data Set, and nothing a person types into a checklist creates or updates a record. If you need a form-to-table pipeline — every completed inspection becomes a row somewhere — use the task_completed webhook or the API to read the checklist's answers and write them where they belong.

A Data Set is not a document store. Each record holds at most 5 KB of cell text across all its fields, which is generous for reference data and useless for a policy. Long documents belong in an Article or a File in the same Library folder.

Limits and Permissions

Limits are enforced when you try to cross them, with a message naming the one you hit, and a CSV import that would exceed a limit is rejected in full. The 500-row Table limit is the one most likely to catch you out, because it applies to the View: a 4,000-record Data Set is perfectly usable in a Table as long as the View you link filters it to 500 or fewer.

Permissions follow the Library model — your Library permission combined with your folder permission on the folder the Data Set lives in. Anyone with view access can open a Data Set, browse its records, switch Views, check Connections and export CSV. Creating, editing fields, records and Views, and Import CSV (Replace) need Library.Creator with Edit on the folder. Deleting a Data Set is Administrator-only, because it may be feeding controls in many templates. Linking a control needs template permissions, and view access to the Data Set is enough. And there is no separate permission for using a linked control in a checklist: anyone who can open the checklist, including people using a public share link, can see and choose from the options the linked View provides — which is the reason not to link sensitive data to a control in a widely shared template.

Lists Inside Templates vs Data Sets

Data Sets are included on the Business plan at $10 per user per month, or $9 on annual billing, along with every other feature — see pricing.

Frequently Asked Questions