Enforce Object Repository = Yes causing validation errors for variable-based selectors

Hi everyone,

I’m facing an issue while working with Object Repository in UiPath.

We have set “Enforce Object Repository = Yes”, and as expected, it is flagging activities that are not added to the Object Repository.

However, the problem is:

  • It is also flagging activities that use variable-based (dynamic) selectors

  • As per general practice, these dynamic selectors are usually handled directly in the workflow and not added to the Object Repository

  • Because of this, we are seeing validation errors even for valid dynamic selectors

For example:

  • In one workflow, a selector is using a variable value

  • Still, it is getting flagged as not part of Object Repository

In our case:

  • The Object Repository is shared across projects

  • So technically, variable-based selectors can be not added to object repository because A variable used in one project may not exist in another project

My questions:

What is the recommended approach for handling dynamic/variable-based selectors in this case?

Should we add such selectors to Object Repository, or keep them in workflow and ignore validation?

@loginerror

@Dhruba_Jyoti_Kalita

ideally we need to follow a specific convention and add the variables in object repo directly..else always individual edits would come into picture

and when you drag a object from object repo by default the variable present in the selector would be auto created

by having specific convention the issue can be handled

Also this helps to keep the selector consistent as well…instead of adding per project or workflow

cheers

@Anil_G Thanks for the explanation

This approach makes sense for maintaining consistency within a project.

But my problem is — how would this work in cases where the Object Repository is shared across multiple projects? Since variable names and usage can differ between projects, wouldn’t that create dependency or mapping issues if the same selector expects specific arguments?

@Dhruba_Jyoti_Kalita

Ideally any component built in library or object repo are project independent…so the naming also should be generic from projects and specific from the activity or actual usage

So using a common name would work across projects as well

If you dont want to use it dynamic in one process then just set the value to variable and it would act as a constant else if needed dynamic then it would act as variable..that depends on how you use in the project

Library or object repo should never have a dependency on the project

Cheers