Infohub (Flow)Concept

Manual Entry Measures

Capturing the numbers no system holds — targets, lab results, downtime reasons — and why they need protecting.

Updated 15 Oct 2026Infohub Docs

Not every number a report needs exists in a system. Monthly production targets live in a spreadsheet. Lab results are written on a clipboard. Budgeted costs come out of a planning meeting. A manual entry measure gives those numbers a proper home in the model, so they aggregate, calculate, chart, and report exactly like retrieved data.

What they are for#

Typical uses:

Targets and budgets — production targets, energy budgets, cost allocations
Laboratory results — moisture, purity, particle size, entered per batch or per shift
Design and reference values — nameplate capacity, headcount, planned running hours
Counts nobody automates — pallets shipped, samples taken, deliveries received
Commentary and reasons — downtime causes, deviation explanations

Once entered, a manual value behaves like any other. Aggregate it, divide by it, chart it, put a limit on it.

Creating one#

Setting	Notes
Retrieval type	Manually entered
Interval	The period a single entry covers
Unit and Format	As for any measure
Default value	What a new period starts at, if anything

There is no connection and no tag, because there is no source system.

Important

Choose the interval the data is actually produced at. A monthly target should be a Monthly measure. A lab result taken per shift should be Shiftly. Getting this wrong forces awkward workarounds later — and note that a manual measure feeding an hourly calculation must itself be at the hourly interval, or the calculation will not find a value at the interval it runs at.

Entering values#

Values are captured through a form — a chart type designed for data entry, placed on a dashboard like any other. Users open it in the browser and type into the periods they are responsible for.

See Forms and Data Capture for building them. Practical points for the measures behind them:

Group measures that are entered together into the same metric, so one form covers a shift handover without hunting.
Set sensible limits on manual measures. A limit that flags an implausible entry catches the misplaced decimal point that would otherwise propagate into a monthly report.
Use enumerations for anything categorical. A downtime reason picked from a list is analysable; the same reason typed freely produces "Blockage", "blockage", "Blocked", and "blokage" as four distinct categories.

The monthly-target-to-daily problem#

The most common manual entry pattern deserves spelling out, because doing it naively produces a wrong answer.

A target is agreed monthly. Reports are daily. You need a daily target to compare against daily actuals.

The wrong approach is entering the monthly figure and letting a daily measure aggregate from it — aggregation goes up the interval chain, not down, so this does not work.

The right approach is a calculated daily measure that divides the monthly target by the number of days in the month, taken from the period rather than assumed:

Convert.ToDouble(Measure_<monthlyTargetId>.Value) / Period.Duration.TotalDays

Using Period.Duration.TotalDays rather than a hard-coded 30 or 31 means February and leap years are handled correctly, without a special case.

The same pattern covers monthly budget to shift target, annual plan to monthly, and any other case where the number is agreed at one interval and consumed at a finer one. It is common enough to be worth putting into a custom function.

Why manual values need protecting#

Manual values are the only data in Infohub that cannot be regenerated.

If a retrieved measure is wrong, you fix the configuration and backfill from the source. If an aggregation is wrong, you correct it and recalculate. A manually entered value that is deleted is gone — the only copy was the one a person typed, and nobody remembers what last March's target was.

Important

Never purge manual entry measures. Housekeeping and data-clearing operations that are safe for Retrieved, Aggregated, Calculated, and Replicated measures are not safe for Manually entered ones. Those four can be rebuilt from their sources; manual values cannot. Before any bulk delete, recalculation, or purge, confirm the scope excludes manual entry measures, and back up first.

This also means manual entry measures deserve a place in your backup thinking. The SQL database backup covers them, which is another reason to verify that backups actually restore. See Backup and Recovery.

Audit and accountability#

Manual entry is where a person's judgement enters the model, and reports built on it get questioned. Design for that:

Keep the measure names unambiguous about who owns them — Target (Planning) invites fewer arguments than Target.
Where the reason for a number matters as much as the number, capture a commentary measure alongside it.
Put manual measures in a folder structure that mirrors responsibility, so it is obvious which team maintains which values.

Handling gaps#

A manual measure will have gaps, because people forget.

Decide what a gap should mean and make it explicit rather than accidental.

Nothing entered means no target — calculations that divide by it should guard for zero or null and produce no value, so the gap stays visible.

Nothing entered means carry the last value forward — use an expression that reaches back:

Measure_<id>.Value ?? Measure_<id>[-1].Value

That is defensible for slow-moving reference values like a design capacity. It is dangerous for targets, because a stale target silently becomes the current one and nobody notices that planning stopped.

Nothing entered means zero — appropriate for counts of things that did not happen, and wrong for almost everything else.

The failure mode to avoid is not deciding, then discovering months later that a chart has been comparing actuals against a target from last year.

Diagnosing manual entry problems#

Symptom	Usual cause
Users cannot type into a period	The form's period is outside the range the measure allows, or permissions
Values entered but calculations ignore them	Interval mismatch — the calculation runs at a different interval
Daily target looks wrong in short months	Hard-coded day count instead of `Period.Duration.TotalDays`
Value disappeared	A purge or bulk operation included manual measures — restore from backup
Free-text categories will not group	Enumeration not used; the values are strings