Group machines into cascades

Treat several machines that run as one line as a single unit.

A cascading group, or cascade, is a set of machines that one part passes through in sequence, grouped so the Assets page reads them as a line instead of as unrelated machines. Each machine gets a step number, and every step after the first reports what fraction of Step 1's output reached it.

Group machines that a part passes through in sequence, where a stop anywhere stops the line. Do not group machines that merely sit near each other. A cascade reports as one unit, so grouping independent machines hides which one is the problem.

Before you start

Sign in as an Organization Owner or Organization Administrator. Other roles see the Cascading Group field and the cascade actions disabled rather than hidden. See Roles reference.
Add the machines first. Cascading Group appears in a machine's Edit dialog, not in Add asset. See Add a machine.
Have two or more machines with sensors reporting. A group with one member draws as an ordinary machine, not as a line.

What a cascading group is

Take a bottling line: a blow molder forms the bottle, a detabber trims the tab left by the mold, a spin trimmer finishes the neck, and a leak detector rejects the bottles that do not hold pressure. Each machine is its own asset with its own counts, so none of them can say how many molded bottles came off the line good.

That is what the group adds. Step 1 is the reference, every downstream step is compared against it, and the comparison is FPY, first pass yield: the percentage of Step 1's parts that reached this step. See FPY.

Groups belong to the organization and a machine belongs to at most one. The step number is per machine, so a group is assembled one machine at a time.

Create a group

You create the group while editing the first machine in the line, then point the rest of the line at it.

On the Assets page, select ⋮ on the line's first machine, then select Edit.
Select the Cascading Group field, then select Create new group.
Type a name that names the line, for example Bottling Line 1.
Leave both toggles off. They are covered in Baseline yield on cycle time.
Select Add. IoTFlows confirms with "Cascading group created" and selects the new group on this machine.
Set Step, the numeric field beside the group, to 1.
Select Edit Asset. IoTFlows confirms with "Asset has been edited".
Repeat steps 1, 2, 6 and 7 for every other machine in the line, picking the existing group from the list and setting Step to 2, 3, and so on.

The Edit asset dialog with the Cascading Group dropdown open in create mode: a name field, an Add button, and the toggles Hide First Pass Yield and Baseline yield on cycle time, with the Step field to the right of the dropdown

The Cascading Group field in a machine's Edit dialog, open in create mode, with the group name, the Step field, and the two per-group toggles.

A machine you leave without a step sorts after every numbered one, so give every member a number.

How grouped cards read

A cascade is drawn differently in each view mode, and only one of them draws it in full.

View mode	What the cascade shows
List	The whole treatment: a group header naming the line, its step count and its part; a Step number on each row; and an FPY column in place of Utilization
Card	The group's cards stay together as a block. The header and FPY appear only when the grid is a single column, so on a phone or a narrow window
Large uptime card	FPY on each machine, and only for a group in cycle-time baseline mode. No header and no step order
Large card, Cycle count	Nothing. The machines draw as ordinary cards

Read a cascade in list view. It is the only mode that shows the header, the step order and the FPY column at a desktop width. See Choose a view mode.

Grouping the page can also dissolve a cascade. Group by left unset or set to Department keeps cascades intact; Status and Machine type break them into individual machines, because those headings cut across the line. A cascade whose machines sit in different departments renders whole, under the department of Step 1.

A cascade in the Assets list view under a header reading Line 6, 5 steps, with the part Bottle 200ml beside it. The first three of its rows are visible: Blow molder, Detabber and Trimmer infeed, each carrying a Step number, a status ring, the machine name and identifier, and hourly production bars.

A cascade in list view: the group header names the line and its step count, and each machine row carries its step number.

FPY across a cascade

Every downstream step is compared against Step 1, not against the step immediately before it:

fpy = this step's good count ÷ Step 1's good count, capped at 100%

For a five-step bottling line that molded 39,000 bottles in the window:

Step	Produced	Loss vs Step 1	FPY on the card
1 · Blow molder	39,000	—	100%
2 · Detabber	38,632	368	99.1%
3 · Trimmer infeed	38,100	900	97.7%
4 · Trimmer outfeed	37,835	1,165	97.0%
5 · Leak detector	37,696	1,304	96.7%

So the figure is cumulative: Step 5's 96.7% is the share of molded bottles that passed the leak detector, not the share of trimmed bottles that passed it. The 532 parts lost between Step 2 and Step 3 is the difference between two rows, which the card does not compute for you.

Each downstream step also carries two numbers under its percentage: parts lost against Step 1, and a rate difference in operations per minute against Step 1's rate. A step running slower than Step 1 is where the line is throttled. Both are hidden on a step that matched or beat Step 1, and its FPY reads 100% rather than more.

FPY reads green from 95%, amber from 80%, and red below that. A step with no operation assigned reads —, because there is no count to compare, which is what Cascade a part and operation fixes.

The rightmost columns of five cascade rows, each showing a part count made, a current rate and a target rate beside its FPY figure. Step 1 reads 39K made, 54.3 ops per minute and 100% FPY in green. The four steps below it fall away from that reference in step: 99.1%, 97.7%, 97.0% and 96.7% FPY, each with its parts lost against Step 1 and its rate difference in red beneath, from minus 368 parts and minus 0.5 ops per minute down to minus 1,304 parts and minus 1.8 ops per minute.

The FPY column in list view. Each downstream step reads its percentage of Step 1's count, with parts lost and the rate difference beneath it.

Baseline yield on cycle time

Comparing against Step 1 assumes the steps handle the same part one for one. Where they do not, turn on Baseline yield on cycle time in the group's settings. Each step is then measured against its own expected output, the parts it could have produced at its operation's ideal cycle time, with no reference step at all.

The group header carries a Cycle-time baseline badge when this is on.

That expected count spans the whole window, not the running part of it, so a stop counts against the number exactly as a slow cycle does. A step down for half the window reads at most 50%. See Performance.

Default to leaving it off. Turn it on when the steps do not run one for one: when a step makes several sub-assemblies per finished unit, when the steps' ideal cycle times differ by design, or when the "line" is a single machine you still want a yield figure for. A one-machine group shows FPY only in this mode, since it has no Step 1 to compare against.

Hide First Pass Yield drops the FPY column from the group's rows and gives the space to the other columns. It is the setting for a group you want held together and ordered without a yield figure. Turning it on forces the cycle-time baseline off and disables it, because there is nothing left for a baseline to measure.

Group settings

Setting	Effect on the card	Effect on reports
Group name	Labels the group header in list view	None
Step	Sets the draw order, and makes Step 1 the reference for FPY	None
Hide First Pass Yield	Drops the FPY column from every row in the group	None
Baseline yield on cycle time	FPY is measured against each step's own ideal cycle time, and the header gains a Cycle-time baseline badge	None

Nothing in this table reaches a report. The Downtimes report and the Advanced Report have no cascade dimension: they list machines individually, whatever groups those machines belong to.

A cascade changes how the Assets page reads, not what a report says. See Available exports.

Cascade a part and operation in one action

When the line changes over to a new part, one dialog switches every machine in the group instead of you editing each one.

In list view, select the part block in the group header, or Set Part if the line has no part yet.
Search for the part by name. The list is filtered by the server, so a part you have not searched for will not be in it.
Select the part. The dialog moves to Assign operations per machine, pre-filled by step order: Step 1 takes the part's first operation, Step 2 its second, and so on.
Correct any machine whose target is wrong, or set it to Don't change to leave that machine alone. The footer counts how many of the group will change.
Select Update N machines. IoTFlows confirms with "Updated 5 machines" for a five-machine line.

This sets the operation each machine auto-detects, the same setting as Switch operation on a single card, see Auto-detect operations. It is what gives every step a count, and therefore an FPY figure.

Two things stop the dialog short. A part with no operations reads "This part has no operations to assign", so define them first, see Parts and operations. Leaving every machine on Don't change reports "Pick an operation for at least one machine".

Each machine is switched by its own request, so a run can half succeed: "Updated 4 machines" alongside "Failed to update 1 machine". Reopen the dialog and apply again to the one that failed.

The Assign operations per machine dialog, opened from the highlighted part block in the group header behind it. A part header shows the part photo, Bottle 200ml, and 5 operations, and below it five rows, each naming a step and machine with its current operation and a dropdown holding the new one. The footer reads 5 of 5 will change beside an Update 5 machines button.

The cascade part dialog on its second panel, assigning one operation per machine, pre-filled by step order, with a count of how many machines will change.

Edit or delete a group

Every change to a group is made from the same Cascading Group field, reached through Edit on any machine.

Rename a group, or change its settings. Select the pencil on the group's row, change the name or either toggle, then select Save. IoTFlows confirms with "Group updated".
Change a machine's position. Set a new Step on that machine and select Edit Asset.
Take one machine out of the line. Select the cross on the Cascading Group field to clear the selection, then select Edit Asset. The machine returns to the fleet as an ordinary card, and the step numbers of the machines left behind do not renumber themselves.
Delete the group. Select the trash on the group's row, then Delete in the confirmation. IoTFlows confirms with "Cascading group deleted".

What does deleting a group destroy? The grouping only. The confirmation says it: "This action cannot be undone. Any assets currently assigned to this group will be unassigned." Every machine stays, with its sensor, its history, its operations and its counts, so a five-step line becomes five ordinary cards. If the delete fails, the toast reads "Failed to delete cascading group" and the group is still there.

A group that drops below two members stops being drawn as a line. It still exists, and it still holds its settings, so adding a second machine back restores the cascade without you recreating anything.