Filtering Attributes on Forms
Narrowing a drop-down to the values that make sense — cascading attribute selection, and filtering which rows a form shows.
A downtime form with sixty reasons in one drop-down does not get filled in accurately. It gets filled in with whichever reason is nearest the top, because scrolling a long list forty times a shift is not a thing people do carefully.
Infohub has two separate mechanisms for narrowing what a form offers, and they solve different problems. They are easy to confuse because both are called filtering.
| Mechanism | Narrows | Use it when |
|---|---|---|
| Cascading attribute selection | The values offered in one attribute's drop-down, based on what was chosen in another | The valid reasons depend on the category, the line, or the product |
| Form attribute filter | Which rows appear on the form at all | One form per area, per line, or per shift, from one event scheme |
Cascading selection: values that depend on another answer#
This is the one that makes long reason lists usable. An attribute's available values come from an enumeration group, and a filter attribute decides which part of the group is offered.
The shape is:
Enumeration group: Downtime Reasons
+-- column: Category Mechanical · Electrical · Process · Planned
+-- column: Reason Bearing failure · Drive fault · Changeover · …
Event attribute "Category" takes its values from the Category column
Event attribute "Reason" takes its values from the Reason column,
filtered by the "Category" attribute
Choose Mechanical in Category, and Reason offers only the mechanical reasons. Choose Planned, and it offers only the planned ones. The operator sees six reasons rather than sixty, and an impossible combination — Planned with Bearing failure — cannot be recorded at all.
Three points to get right when configuring it:
- The group and the column are both part of the setup. An attribute is pointed at an enumeration group and then at a specific column within it. Two attributes drawing on two columns of one group is what makes the cascade possible.
- The filter attribute must be on the same event. The narrowing is driven by another attribute's value on the same event period, so the driving attribute has to be answered first.
- Order the attributes so the driver comes first. Nothing enforces it, and a form that asks for Reason above Category is confusing even though it works.
This is a data-quality mechanism, not a convenience. The value of a cascade is not that it saves scrolling. It is that the combinations recorded are valid by construction, so a Pareto by category and a Pareto by reason reconcile. Reason lists maintained without one drift into Other, Other (2) and misc, and no amount of later cleaning recovers what actually happened.
Form filters: which rows the form shows#
The second mechanism works at the form rather than the attribute. A form section can carry a filter on an attribute value, so only event periods whose attribute matches are listed.
That is how one event scheme serves several forms:
- A form per production line, filtered on the
Lineattribute. - A form for unplanned stoppages only, filtered on
Categorybeing anything exceptPlanned. - A shift-handover form showing only events still lacking a reason.
The filter can name specific values, or draw them from an enumeration group column — and it can itself be driven by a filter attribute, so a form's row filter can cascade the same way a drop-down does.
The point is that the events are not duplicated. One event scheme holds every stoppage; the forms are views onto it. Splitting by creating an event scheme per line instead would give you separate data that then has to be recombined for site-level reporting.
Choosing between them#
Ask what you are trying to restrict.
- Restricting what someone may enter → cascading attribute selection.
- Restricting what someone is shown → a form filter.
- Both, usually: a line-specific form that also offers only that line's reasons.
They compose cleanly because they act at different levels, and neither changes the underlying event data.
Diagnosing#
| Symptom | Likely cause |
|---|---|
| A drop-down shows every value regardless of the other answer | No filter attribute set on that attribute, or it points at the group rather than a column within it |
| A drop-down is empty | The driving attribute has no value yet, or its value matches nothing in the filtered column |
| Impossible combinations still get recorded | The attributes draw on separate enumerations rather than columns of one group |
| A form shows events from other lines | No form filter on the distinguishing attribute |
| A form is empty | The filter matches no event in the period — check the filter value against what is actually recorded, including case |
| The cascade works in one form but not another | Cascading is configured on the attribute and applies everywhere; a form filter is per form. Check which one you actually configured |