topic RE: Salesforce Web/UI Automation in Product Forum

Salesforce Web/UI Automation

SamAssaf — Sat, 19 Sep 2020 00:06:00 GMT

Hi Blue Prism Community!

I just wanted to run this by you guys in hopes that at least some of you have run by this problem before:

I'm working on a project that requires us to automate a lengthy task in Salesforce. Now, I know that the Digital Exchange has the awesome Salesforce Skill but a strict constraint in this project is to not use the API. However, the fields in Salesforce records on the web client do not have any identifying attributes.

Using Web Path has not been helpful since it varies from record to record and using wildcards in Web Paths on a complex site makes the robot very slow as it traverses all possibilities.

Has anyone had any luck with Salesforce and is willing to share some knowledge?

Thanks!

------------------------------
Sam Assaf
Senior
EY
Montreal QC
------------------------------

RE: Salesforce Web/UI Automation

SamStone — Tue, 22 Sep 2020 10:45:00 GMT

I've never tried using the UI for Salesforce, but I've heard it is quite a nightmare to spy. I swear by the API as it's lightning fast (and maybe because I had quite a bit to do with creating it....)

I would challenge the constraint to not use the API, a big factor you could use in doing so is cost. The API takes miliseconds to do a task that could take minutes in the UI. Multiply that out by any decent number of cases and you're looking at huge savings on resource/licence utilisation by going for the faster option. Any senior person putting a blocker on the API may reconsider when shown such numbers.

------------------------------
Sam Stone
CoE Build Lead
Blue Prism
------------------------------

RE: Salesforce Web/UI Automation

PatrickAucoin — Tue, 22 Sep 2020 20:24:00 GMT

Hi Sam,

First I want to echo my colleague Sam's reply and advise you to try to reconsider the API. I have some suggestions below, but the processing time will take longer.
I just had a similar problem on a different web application, and here is what worked for me:

Look up the tree structure of the HTML from the target element. There is usually a nearby element that you are able to match on unique attribute(s), often Web text in combination with one or two others. Let's call this the label element. Compare the Web path of this label element with the Web path of the target element. If one element is dependent on the other, there will be a pattern.

When the page loads, you can read the path of the label element and use it to calculate the path of the target element based on the pattern you observed. Use the new path to dynamically match on the target element (Test to make sure the pattern is correct and consistent). Here is a mockup of what that could look like:

Another suggestion is to take a closer look at the URL structure. What looks like a random string can sometimes be a unique/persistent identifier that can be useful. Part of your Salesforce URL is probably the unique ID for that record, for example.

------------------------------
Patrick Aucoin
Senior Product Consultant
Blue Prism
------------------------------

RE: Salesforce Web/UI Automation

BrianChristense — Wed, 23 Sep 2020 05:30:00 GMT

We tried to work with salesforce UI. The end result was a monster of a bot and it ended up being scrapped because salesforce ui is too dynamic.

We contacted the salesforce team and got an API access, now we do everything through the api. It's simpler than automating the UI and a rock stable.

------------------------------
Brian Christensen
Developer
TDC
Europe/Copenhagen
------------------------------

RE: Salesforce Web/UI Automation

SamAssaf — Wed, 23 Sep 2020 14:44:00 GMT

Thank you! Your answer echoes @SamStone's and is unfortunately what I was afraid of. The client insists that there are too many hurdles associated with exposing the API.

I have tried @PatrickAucoin's solution but the problem is twofold:

The UI is so dynamic that even spying "labels" requires wildcards in the web path and that just hangs Blue Prism.
The amount of Web Path manipulation you'd have to do at the end to traverse from the "label" to the actual field is quite complex.

------------------------------
Sam Assaf
Senior
EY
Montreal QC
------------------------------

RE: Salesforce Web/UI Automation

pino.agostino — Thu, 24 Sep 2020 01:05:00 GMT

Hello Sam, while I understand the client might insist on the hurdles... I believe it will be crucial to educate the client on the risk vs reward factors as stated earlier...
At the end of the day, the true value in the automation and overall solution is what should prevail, If it doesn't... then we have all failed our customer(s) and ourselves. 😉

------------------------------
Pino Agostino
------------------------------

RE: Salesforce Web/UI Automation

dcternes — Wed, 27 Jan 2021 08:50:00 GMT

Hi @Sam Assaf

I realise your post was quite a while ago, but perhaps you or others will get value from this in the future.

I completely agree that the API approach is the way to go, but in the event that the real world intervenes and you're forced to use traditional spying, this is what worked for me. BTW, I'm using the Lightning interface - I guess you are too - so I've no idea if this works for SF Classic too.

It seems that issue with Lightning is that every time you click on a different object (eg: from Account #1 to Account #2 to Account #3) it appends the new view to the original DOM. Presumably, this is so that it can quickly navigate back-and-forth between the various objects that you've selected. For BP robots though, it means that the field you're trying to spy/retrieve is never at the same path in the DOM. Nightmare!

You can see this from the screenshot below. This is the XPATH to the same field in three different accounts. The only difference is line 14.

Hence we end up creating dynamic paths, looking up parent URLs, modifying that offending <DIV>, and stuff like that which becomes completely unwieldy.

The solution that's worked for me is to refresh the browser each time you go to a new SF screen. The browser refresh resets the DOM and therefore the Line 14 DIV is always #1 and the XPATH to the field is always consistent.

So, at design-time, I goto a page, I refresh the page, I spy the page controls; at run-time, I goto a page, I refresh the page, I read the page controls. Something like this:

I'm only writing my objects now (I discovered this thread 'cause I was tearing my hair out) so perhaps some other problem will crop up, but thus far this approach is working for me.

------------------------------
Dan Ternes
CTO APJ
Blue Prism
Asia/Hong_Kong
------------------------------