Salesforce automation

The DOMXPath property is your best friend in these situations.

Relative Xpath: This is a shorter path that refers to an element you want to identify. A relative path starts with a // symbol. For example, the relative XPath for this topic would be //*/@id="cloud-using-recorder-action"]/div/pv1]

Using the Capture action (automationanywhere.com)

With XPath, you can find an element by:

• Text content
• Relation to other nodes (think anchors)
• Type of element
• Index
• Size and coordinates
• Attributes
• Classes

Additionally, you can nest them inside each other and use string, logical, and mathematical operators.

Honestly, when working with websites, I almost always disable all the properties in the recorder action except for the XPath. And it would seem like I’m not the only person who favors this approach, there is an extension in the chrome web store which features a hotkey to disable all the properties in a recorder action except for XPath: Automation Anywhere Hotkey - Chrome Web Store (google.com)

If you want to play around with XPath and experiment with dynamic HTML UI elements, you can use this website: https://rpachallenge.com/ 

I can’t recommend enough reading the w3schools.com guide to XPath:

XPath Syntax (w3schools.com)

XPath Axes (w3schools.com)

XPath Operators (w3schools.com)

XPath Examples (w3schools.com)

Thank you very much for taking a time to reply. I found this very helpful.

 I have just checked the domxpath of a particular button before maintenance and domxpath after the maintenance and I see changes also in domxpath :/

That shouldn't be a problem!

Take for instance this button in Salesforce: 

When I capture it with the recorder, the properties look like this:

And the XPath looks like this:

/html/body/divv4]/divv1]/sectionn1]/divv1]/divv2]/divv2]/divv1]/divv1]/divv1]/divv1]/divv1]/divv1]/divv1]/divv1]/divv2]/divv1]/divv1]/divv2]/divv2]/divv1]/ull1]/lii1]/divv1]/divv1]/divv1]/buttonn1]

As you can see that XPath is way too specific, and if we inspect the HTML element with the Microsoft Edge Developer Tools, it’s looks a little scary.

But if we start collapsing a few nodes, we start to notice more attributes that, at least in theory, should never change.

In this same window, you can press CTRL + F and type in your XPath expression to test it and see how many elements would be returned.

The new XPath expression that was entered in the search box would return 10 elements, 1 for each email button on that list.

At this point, you could be modify the expression in different ways depending on your use case. 

For example...

//ahtext()='Phyllis Cotton']/ancestor::divs@class='clickableCardArea']//button]@title='Email']

In essence, this XPath expression is looking for a button with the title "Email" that is located within a div element with the class "clickableCardArea", and this div element is an ancestor of an anchor element containing the text "Phyllis Cotton".

Or if your requirement is something much simpler, such as pressing the first button on the list, adding the index to the expression would suffice:

//button"@title='Email']e1]

Once you're happy with your XPath expression, you can plug it in the DOMXPath attribute of your recorder action:

But wait, there's more!
Did you notice the (x) button in the bottom right corner? Well…