Move Row Automation lagging terribly

@Paul Newcome After another 20 minutes, everything moved at once, all 142 rows. 🤷‍♂️

It makes no sense. A move row automation that is supposed to fire off when rows are added should move the rows within a reasonable amount of time, no more than 2-3 minutes.

And wouldn't you know it, but there are 16 rows sitting in the collection sheet that have been there for 30 minutes now, when they're supposed to move immediately too.

Edit: the 16 rows that are sitting there were all added nearly 2 hours ago!

That's the whole idea behind the leapfrogging. (See that link for a description of the process and the trouble I encountered in May.) Even if the final destination sheet is large, or has many formulas, the form entries to the collection sheet should be instant, and then the move rows from the intermediate sheet to the final should at least happen continuously, even if slowly. Even if it takes a minute to move each row, at least they're moving. These were just sitting there for hours, then suddenly moving all at once.

The destination sheet is where a metrics sheet is getting its data; if the rows take hours to arrive, the supervisors who are looking for count discrepancies are left waiting around instead of resolving any bad counts. I need the formulas in that final sheet or else there's no point.

No, there are no dates involved and not TODAY function in any formula.

My fields in the collection sheet and the intermediate sheet are Primary Column (defaults to 1), Bin Location (4 char alphanumeric), Product Code (8-15 char alphanumeric), Serial # (8-17 char alphanumeric), Warehouse (7 char alpha).

My Final landing sheet has the 5 columns above, plus:

Duplicate Check, making sure they haven't entered the same combo of bin, product, and serial #: =COUNTIFS([Bin Location]:[Bin Location], [Bin Location]@row, [Product Code]:[Product Code], @cell = [Product Code]@row, [Serial #]:[Serial #], @cell = [Serial #]@row)

SKU, some of our boxes from different factories have bar codes that don't contain our customer facing SKU numbers, so this series of IFs and INDEX/MATCH resolves the scanned product code into a recognizable SKU: =IFERROR(IF(ISBLANK([Product Code]@row), "", IF(LEN([Product Code]@row) = 6, INDEX({Model code and EANMat}, MATCH([Product Code]@row, {Model code and EAN data model}, 0)), IF(LEFT([Product Code]@row, 1) = "0", INDEX({Model code and EANMat}, MATCH(MID([Product Code]@row, 3, 15), {Model code and EAN data Ean}, 0)), IF(OR(MID([Product Code]@row, 4, 1) = "-", MID([Product Code]@row, 5, 1) = "-"), [Product Code]@row, INDEX({Model code and EANMat}, MATCH([Product Code]@row, {Model code and EAN data Ean}, 0)))))), [Product Code]@row)

ME Indoor Product Code, Some of our indoor units do not list any product code at all, the product code has to be extracted from part of the serial number bar code:=IF(LEFT([Product Code]@row, 1) = "L", MID([Product Code]@row, 2, 6))

Lastly, on the metrics sheet called Model Count:

Supervisors scan the Bin Location and Product Code in to a row, then hand count the boxes for that Product in that Bin Location and enter the count. Then a column called Total Serials counts the rows in the Final Landing sheet that have the same Bin Location and Product Code.

=COUNTIFS({Serial Count bin}, [Bin Location]@row, {Serial Collection product code}, @cell = [Product Code]@row)

Another column compares the hand count to the count of collected serial numbers to generate a RYG ball - Green for matched counts, Yellow for more serials than hand count, Red for more hand count than serials.

Now I'm wondering if the Total Serials count from the Model Count metrics sheet is slowing things down - what if I move the rows from Final Landing into another sheet, since Move Row only moves the formula results, not the formulas, and have Model Count look there to count the Total Serials instead?