The Dynamic Sensor Recorder is a form field that lets a user record live temperature readings from one or more IoT sensors on the same form, all at once.
Unlike the single Sensor Recorder field — where the template author hard-wires exactly one sensor — this field lets the author define a pool of allowed sensors, optionally pre-load some of them, and (optionally) let the person filling in the form add or remove sensors on the fly. Each sensor records independently against the same set of temperature targets.
Where to find it: Form template editor → drag in a Dynamic Sensor Recorder field → open its properties.
When to use it
Reach for the Dynamic Sensor Recorder when a single form needs to capture readings from a variable or multiple set of probes — for example:
- A delivery where you probe several pallets, each with its own sensor.
- A cook/chill step monitored by two or three probes at once.
- A process where the number of sensors isn't known until the operator is on the floor.
If you only ever record from exactly one fixed sensor, the single Sensor Recorder field is simpler. The Dynamic Sensor Recorder is the right choice the moment you need more than one, or you want the operator to choose which sensor(s) from an approved list.
How it works
| Concept | What it means |
|---|---|
| Allowed Sensors | The pool of sensors a user is permitted to record from on this field. Nothing outside this list can ever be selected. |
| Default Sensors | Sensors that are pre-added (already showing as cards) the moment the form opens. Must be a subset of Allowed Sensors. |
| Runtime add | Whether the person filling in the form may add more sensors (from the allowed pool) or remove unstarted ones while completing the form. |
| Targets | Temperature conditions (e.g. ≥ 75 °C within 30 min) that every sensor on the field is measured against. |
| Max Duration | An overall cap, in minutes, on how long a single recording runs. |
| Slot / card | Each sensor the user is recording from appears as its own card with a chart, live readings, and the targets table. |
A sensor can only appear once per field — once it's picked in one card it disappears from the picker in the others.
Configuring the field (template author)
Drop a Dynamic Sensor Recorder field onto the template and open its properties. There are three configuration sections.
1. Sensor Settings
- Allowed Sensors — a multi-select of every sensor the user is permitted to use. This is required; if it's empty, runtime users will see a warning and won't be able to record anything.
- Recording Max Duration (min) — the longest a single recording will run before it stops automatically. Leave blank for no cap.
- Allow user to add sensors at runtime — tick this to show the + Add Sensor button (and per-card remove buttons) to the operator. Untick it to lock the form down to exactly the Default Sensors you specify.
2. Default Sensors
Sensors listed here are pre-added when the form opens, so the operator can start recording immediately without picking anything.
- Use the + Add Default Sensor picker to add one. The picker only offers sensors that are in Allowed Sensors.
- Remove a default with the trash icon next to it.
- If you later remove a sensor from Allowed Sensors that's still listed as a default, it's flagged (no longer allowed) in red — clean it up before saving.
Tip — locked-down forms. Set your Default Sensors and untick Allow user to add sensors at runtime to produce a form with a fixed, non-editable set of sensors. This is the way to reproduce the old "one fixed sensor" behaviour, or a fixed set of several.
3. Targets (max 5)
Targets are the temperature conditions every sensor on this field is judged against — each sensor's card shows the same targets table, scored independently. Click + Add Target (up to five) and fill in each row:
| Column | Meaning |
|---|---|
| Name | Label for the target, e.g. Core Temp or CCP2. |
| Condition | >= (at or above) or <= (at or below) the Value. Use >= for a cook/heat target and <= for a chill/cool target. |
| Value | The threshold temperature, in °C. |
| Duration Type | At or Under = must be reached within the time limit; At or Over = can only be met at or after the time limit (a minimum hold before it counts). |
| Duration (min) | The time constraint, in minutes. 0 = a checkpoint (must be reached, no time limit). |
| Arm | Ignores readings until the probe has first been hotter than the value. Cooling (<=) targets only. See below. |
| Reset | Reaching this target restarts the timer for the targets below it — used to chain cooling stages. See below. |
Arm — for cook-then-chill (cooling) targets
A cooling target (<=) is usually only meaningful after the product has been hot. Without help, a ≤ 21 °C target would be marked "met" the instant recording starts if the probe already reads below 21 °C (for example, a cold probe before it is inserted).
Arm prevents this. When Arm is ticked, the target ignores readings until the probe has first gone strictly above the value. Only then does it start looking for a reading at or below the value.
Example — a cook-then-chill CCP. Target CCP2, Condition ≤ 21 °C, Arm ticked:
|
Arm is automatically switched on when you choose a <= condition, and switched off (and disabled) for >= conditions, where it does not apply.
Reset — chaining cooling stages
Reset lets you build a multi-stage cook/cool profile where each stage's clock starts when the previous stage is achieved. When a target with Reset is met, the timers for all targets below it are re-anchored to that moment (instead of to the start of recording).
For example: a cook target ≥ 75 °C with Reset on, followed by a chill target ≤ 21 °C within 120 min. The 120-minute cooling clock does not start until the 75 °C cook is reached, so the chill window is measured from the end of cooking — exactly as a food-safety cooling rule requires.
Recording (operator)
When the operator opens the form, each sensor appears as a card:
- Pick a sensor (if the card is empty) from the dropdown — it lists only allowed sensors not already in use on another card.
- Press Start Recording. The chart, live readings (Start Time, First/Last Reading, Elapsed, Time Remaining) and the targets table appear. (The Start Recording button only becomes usable once a sensor is selected for that card.)
- Each target shows a live status — Not started, Waiting, Pending, Met ✓, or Failed ✗ — plus when and at what temperature it was achieved.
- + Add Sensor adds another card (only when Allow user to add sensors at runtime is on and there's still an unused allowed sensor). The button disappears once every allowed sensor is in use.
Target statuses
- Not started — the target's clock hasn't begun: either its Reset stage above it isn't met yet, or an Armed cooling target hasn't yet gone above its value.
- Waiting — an At or Over target whose minimum time hasn't elapsed yet.
- Pending — armed / running and waiting for the condition to be satisfied.
- Met — the condition was satisfied; the row records the time and temperature of the reading that met it. Once Met, a target's result is locked for the rest of the recording.
- Failed — an At or Under deadline passed before the target was reached.
Tip — the Met temperature reflects your sensor's reporting interval. The Met time and temperature come from the actual reading that satisfied the target. If a sensor reports infrequently, the reading that crosses the threshold may already be a little past it — e.g. a ≤ 21 °C target shown as Met at 12.7 °C because that was the first reading after the probe dropped below 21. A shorter reporting interval captures the crossing point more precisely; it does not change whether the target passes.
|
What you can and can't change mid-recording
- Before a sensor starts recording, its card shows the picker and a remove (✗) button — you can swap the sensor or delete the card.
- Once recording has started on a card, that card locks: the sensor name becomes fixed text, and the picker and remove button disappear. This protects the audit trail — a reading is always tied to the sensor it actually came from.
When a target fails
A target fails when its time limit runs out before the temperature reaches it. Under When a target fails in the component's settings, the template author decides what staff must do next. These settings are off unless you tick them, so existing templates behave exactly as before.
| Setting | Effect |
|---|---|
| Require a corrective action before the form can be confirmed | A corrective action panel appears on the form when a target fails, and the form cannot be confirmed until it is filled in. The other settings appear once this is ticked. |
| Suggested actions (one per line) | The choices offered to staff, for example “Product held for QA assessment”. Staff pick one of these or type their own. |
| Raise a non-conformance | Recording the action also raises a non-conformance against the form, with the action logged on it as a closed corrective action. |
| Put the form's batch on hold | For a form opened from a batch, recording the action also puts the batch on hold. |
When a target fails, staff see a panel headed “<target> failed — record a corrective action” with “This form cannot be confirmed until it is recorded.” They choose the Action taken (or Something else… to type their own), describe What happened, and save. The panel tells them in advance “A non-conformance will be raised.” or “The batch will be put on hold.” when the template says so. Once saved, the panel reads “Corrective action recorded” with the failed targets, the action, who recorded it and when, and the non-conformance number.
Each sensor card has its own panel: a failed target on one sensor needs its own corrective action, and the form cannot be confirmed until every sensor with a failed target has one. Trying to confirm first is refused with the message “<label>: corrective action” must be entered before confirmation. The sensor keeps recording after a target fails; the corrective action is about the product, not the probe.
The corrective action is printed on the form PDF under the recorder's targets. The same settings are used by the Cooling Log, which records temperatures entered by hand, and its article has screenshots of the panel.
Celsius and Fahrenheit
Targets are entered in the Form Builder in the account's temperature unit, set by an admin under Account Settings → Temperature unit (every account starts on Celsius). The recorder on the form always shows its device's own unit: set the device to Fahrenheit in its IoT settings if that is what you work in. Changing the account unit never changes a recorded value or a target; only how they are shown.
QA check — "All Targets Passed"
If the field's QA Check is set to All Targets Passed, the form's QA result fails unless every target on every recorded sensor was Met. Failures are listed per sensor in the form's QA summary (e.g. "sensor Chiller 2: targets not met — CCP2"). If no sensor recorded at all, the check reports that no recording was captured.
Behaviour & data notes
- One sensor per card. A sensor that's already selected in one card is removed from the picker everywhere else on the field. You can't record the same sensor twice on one field.
- Identity is captured at start. When a card starts recording, the sensor's name is snapshotted into the saved reading and preserved for the life of the form, even if the sensor is later renamed in IoT Device admin. This keeps historical forms accurate.
- Started recordings can't be removed. The remove (✗) button is intentionally hidden once a card has a start time, so an operator can't discard a reading that's already been taken.
- Empty field saves as nothing. If no sensor has been added or recorded, the field stores no value (rather than an empty list).
- Targets are shared, scored separately. All sensors share the same target definitions but each card tracks its own achievements.