My UiPath bots are constantly breaking because our internal CRM changes its web selectors every two weeks. I am spending more time on maintenance than new development. How are you all building more resilient bots? Are you using Anchor Base activities or moving toward Image Recognition to handle these frequent UI shifts?
3 answers
We moved away from strict selectors last year and started leveraging "AI Computer Vision" for our most unstable applications. While it takes a bit more processing power, it is far more reliable than relying on fluctuating CSS classes or dynamic IDs. Another trick we use is creating a "Centralized Object Repository." This allows us to update a selector in one place and have it reflect across all our processes instantly. It hasn't completely eliminated maintenance, but it has cut our rework time by nearly 40%. I highly recommend looking into "Fuzzy Selectors" as well, as they allow for a certain degree of variance in the attributes before the bot throws an exception.
Are you find that the AI Computer Vision significantly increases the execution time of your unattended bots compared to the standard selector approach?
We started using "Wildcards" in our selectors to ignore the dynamic parts of the ID. It’s a simpler fix than AI but works for about 70% of our web-based issues.
I agree with Sarah. Wildcards are a great first step. We also combined them with "Attribute Filtering" to ensure the bot is looking for the right tag name instead of just a random ID.
To answer your question, Michael, there is a slight latency hit, usually around 200-300ms per interaction. However, when you compare that to the hours spent manually fixing a broken bot and restarting a failed production run, the trade-off is absolutely worth it. We only use it for the "problematic" elements, not the entire workflow. This hybrid approach keeps our execution speed high while ensuring the bot doesn't crash the moment a developer changes a button's color or position.