The :eq() syntax is actually valid in PAD selectors Microsoft's own docs use exactly this pattern with %LoopIndex% to click rows in a list. So the syntax is not the core issue.
The real problem is that after navigating away and coming back, the browser reloads the page and the DOM is rebuilt. PAD's cached UI element reference from before navigation is stale, so it fails to find the element.
The fix is to re-capture the element on every iteration rather than relying on a cached reference. Here is the correct structure:
1. Set LoopCounter = 0
2. Loop (start: 0, end: total rows - 1)
a. Wait for the table to be present (use "Wait for UI element" on the table container)
b. Click web link / Click UI element using the dynamic selector each time fresh — do NOT rely on a pre-captured element that was stored before the loop started
c. On the detail page: download the CSV
d. Go back
e. Wait (your 10 seconds is fine, but "Wait for UI element" is more reliable than a fixed wait)
f. Increment LoopCounter
3. End Loop
The key change: make sure the Click action uses the selector with %LoopCounter% directly in the selector text at the time of clicking, not a UI element reference captured before the loop. In PAD, edit the selector in Text mode to something like:
div[id*="grid"] > div:eq(%LoopCounter%)
And make sure %LoopCounter% starts at 0 if the first row is :eq(0), or 1 if the first data row is :eq(1) (header rows may offset the index).
Also check: if the table has a header row, :eq(0) is the header. Your data rows likely start at :eq(1). Try manually testing the selector in the PAD selector builder with a fixed value first to confirm the correct starting index before running the loop.
Best regards,
Valantis
✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.
❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).
🏷️ For follow-ups @Valantis.
📝 https://valantisond365.com/
