Configurable Selector

Help Something Else
1

HI do any of you guys try to make configurable selectors?
we are making automation for a process, the process involves a website that have UI changes.

one of my team have a plan to use configurable selector, so that we can easily update selectors without editing the UiPath codes

2
  1. Use Configurable Selectors by storing selectors in Config.xlsx, JSON, or Orchestrator Assets.
  2. Read selectors dynamically and use them in Click, Type Into, and other UI activities.
  3. Avoid unstable attributes like id, idx, or dynamically generated values.
  4. Use stable attributes such as aaname, tag, title, or class.
  5. Apply wildcards (*) for attributes that change frequently.
  6. Use UiPath Object Repository to manage selectors centrally.
  7. Enable Fuzzy Selectors to handle minor UI changes automatically.
  8. Consider Computer Vision for highly dynamic websites where selectors often break.
  9. Create reusable workflows/components so selector updates are needed only in one place.
  10. This approach reduces maintenance effort and avoids editing UiPath workflows whenever the website UI changes.*
3

can you show me an example of number 1 where it stored in config?

4

You can add values like any number you are getting in selector in config.

5

You could use UI library

In such case you store UI descriptors (selectors) in a separate library.
In case of UI change you update UI descriptors in the library, not the process.
Then you link you process to the updated library and all activities will automatically use the updated UI descriptors.

Cheers

6

Hi @shanti_18,

Yes, this is a common and recommended approach, especially if your application’s UI changes frequently.

Store selectors in an external file and load them during initialization. Your activities then reference these values instead of hardcoded selectors. While this makes updates easier, selectors are XML strings, which can be difficult for non-technical users to edit and aren’t validated until runtime.

UiPath’s built-in feature is designed exactly for this kind of a scenario. Package your UI elements into an Object Repository library and reference descriptors instead of raw selectors. When the UI changes, simply update the descriptor in the library, publish a new version, and update the library dependency in your projects. No workflow changes are required, every activity using that descriptor automatically picks up the updated selector.

Cheers!

7

Hi @shanti_18,

Yes, configurable selectors can work, but they can become difficult to maintain as the number of selectors/elements grows.

Instead, I recommend using the Object Repository for each application. If the UI changes, you only need to update the affected element in the Object Repository, publish the library/package, and then upgrade it in the dependent processes. This approach is easier to maintain and follows UiPath best practices.

Thanks!

8

Hi,

We have an application where in one of the pages the selectors are very unstable and change very often, so we kept those selectors in the config file, mind you the config file is outside the project folder in a shared folder, so that we don’t have to compile the code again.

9

Then you can store the selectors in Config, Assets, or a Storage Bucket file. This allows you to update the selectors without modifying or republishing the automation package.