I have a couple of questions regarding the Click activity and its verification property with the retry input.
Functionality of Retry Input: How does the retry input function within the Click activity? Does it rapidly repeat the action, checking and executing multiple times within the specified timeout duration?
Use Case Comparison: Why would one choose to use the retry input property within the Click activity over implementing a retry scope? In which scenarios would each approach be more advantageous?
This will retry only once if the desired value if main functionality fails.
It’s a quick fallback functionality in case main functionality didn’t work. Retry scope requires additional conditions and configuration which will not be practical for every activity. Hence verify execution is helpful and more convenient.
Verify execution is same as using retry scope without need to configure two more activities and makes the flow look better
It would retry the same activity till the verification action is succeeded or the timeout is reached
Retry scope also works in same way but it looks bigger in the flow and needs multiple activities
Reason for including verify execution is in rpa many times you might see some clicks not happening or type into not eorking as expected and all and retry has to be used multiple times instead verify stage is helping in this so that we need not configure the retry for each activity and automation can be made more stable
If you have your activity’s timeout set to 30 seconds, and the verification retry set to 10 seconds, then it will attempt the click up to 3 times, every 10 seconds.
Because it’s much simpler and allows direct use of modern selectors to define the target to check for after executing the action. It’s like having a Check App State and Retry Scope built into your Click activity. Why use a half dozen activities when you can just use one?
