Core Concepts
Four objects account for almost everything in CheckFlow. Understanding how they nest — and which one holds the data — makes the rest of the documentation straightforward.
The Model
Read it in one sentence: a template contains tasks, tasks contain controls, and running a template produces a checklist that holds the answers.
Template and Checklist
A template is the blueprint. You write it once and it defines what every run will look like: the tasks, their content, who they are assigned to, when they are due, and which rules govern them.
A checklist is one run of that template. Create an Invoice Approval template once, then run a checklist each time an invoice needs approving.
| Template | Checklist | |
|---|---|---|
| How many | One per process | One per run |
| Holds | Tasks, content, behaviour | A copy of all of that, plus the answers |
| Changing it affects | Every checklist created afterwards | Only that checklist |
| Versioned | Yes, on each save | No |
The rule to remember: changing a template does not reach back into checklists that already exist. That is deliberate — a completed checklist is a record of what happened at the time, and editing the template must not rewrite history. See Template Versioning.
Task and Heading
A task is one completable step. It has a checkbox and a status, and it can carry a due date, assignees and tags.
A heading looks similar in the task list but has no checkbox. It is a read-only divider for grouping a long list into sections. It cannot be completed, assigned or reported on.
Task status is not just complete or incomplete. A task can also be Not Applicable — skipped deliberately — or halted, meaning blocked until an earlier task is done, or hidden by a conditional logic rule.
Controls
Everything inside a task is a control, and there are two kinds.
| Content controls | Input controls | |
|---|---|---|
| Purpose | Show information | Capture an answer |
| Editable by the reader | No | Yes |
| Can block task completion | No | Yes, if marked required |
| Examples | Text, Image, Video, File, Mail-To, Embed, Separator | Short Text, Dropdown, Date & Time, Members, File Upload, Table |
Content controls are written once in the template and appear unchanged in every checklist. Input controls are empty in the template and filled in during the run — which is why the answers live in the checklist rather than the template.
See Control Types for the full capability matrix.
Where the Answers Live
This is worth stating on its own, because it explains a lot of otherwise surprising behaviour.
Answers belong to the checklist. The template holds the questions; the checklist holds the answers. So:
- Editing a template never changes an answer somebody already gave.
- Deleting a checklist destroys its answers permanently — there is no copy in the template. See Managing Checklists.
- Reporting on answers means reporting across checklists, which is why Reports is organised by checklist rather than by template.
What Sits Around the Model
Once the four core objects make sense, everything else attaches to one of them:
| Feature | Attaches to | What it does |
|---|---|---|
| Conditional logic | Template | Shows and hides tasks and controls based on an answer |
| Halt tasks | Task | Blocks later tasks until this one is complete |
| Parameters | Template | Values supplied when the checklist is created |
| Dynamic values | Control | Fills one control from another, or from global data |
| Data Sets | Control | Supplies a control's options from managed reference data |
| Tags | Checklist, task, library item | Cross-cutting labels for finding related things |
| Schedules | Template | Creates checklists automatically on a recurrence |
| Permissions | User | Controls who can reach each of the above |
Related Pages
- Glossary — the precise meaning of every term used here.
- Getting Started — building the model in practice.
- Control Types — every control and what it supports.
- Templates Overview — how a template is put together.