I understand the theory behind this solution and it appears to work, but I don’t understand the workflow when it is executed step-by-step (below). Could somebody help me out here
When page is loaded, this is the view (probably less than 10 repeating group cells loaded).
By the end of the 1st workflow, this is the view. Note that the custom state has a value of 178 (which is the number of repeating group cells loaded on the page at that time).
It is the next workflow that I don’t understand.
- The next workflow is only executed if the actual number of repeating group cells in the database is greater than than the number of repeating group cells loaded on the page (temporarily stored as a number via a custom state). This is the highlighted text below.
According to the below evaluators, the actual number of repeating group cells in the database is 178. Whereas
s the number of repeating group cells loaded on the page is apparently empty (it should be 178 according to the custom state previously set in step 2 of my post).
In the end, this workflow is executed because 178 is of course greater than an empty value, which results in the below view.
To summarize, the scrolling to the very bottom of the repeating group is nice, but I’m unsure that the workflow used to get to this result makes sense (since, in this case, 178 or whatever number of database entries is present, will always be greater than an empty custom state). Essentially, this is just a workflow that scrolls to the bottom twice. In fact, I have a workflow that just scrolls to the bottom of a repeating group twice in my project, and this works fine and is much more simple (without the need to set custom states). Could someone clarify or correct my interpretation?