In Salesforce’s Spring ’21 release there will be changes to some components that may cause failures in your automation scripts. Things like New, Edit, and Clone Pop-ups, Lightning Console Tab, App Launcher and App flexipages, and more have changed from Aura Components to Lightning Web Components (LWC), causing some changes to the behaviors in the DOM.

How will this affect your automation scripts, you may ask? First let’s quickly go over these changes.

Understanding the Changes

The biggest change that will affect any existing/current Automation scripts that you have is that some of the locators for these buttons, etc. have changed. If, for instance, you were grabbing the New Button in the Related Tab for a Custom Object, the old locator was something like:


The new locator to grab it will be:


Or if you were trying to get an Input field that was called First Name from the Contact record page, you may have used a locator similar to this:

//span[text()=’First Name’]/parent::label/following-sibling::input[@placeholder=’First Name’]’

The new way would be to use something more concise and stable like:

//input[@id=string(//label[.=’First Name’]/@for)]

Similar changes were done to the Pop-up buttons and fields, Lightning Console Tabs, App Launcher and App flexipages, as well, so there may be quite a few locators that need to be updated.

What Does It Mean?

So what does this mean for you and your automation scripts? Well, it means that some time will need to be put into updating these scripts as they will be failing until they are updated (after Spring ’21). The time needed will vary based on where/what was done, but can basically be broken down into two groups: updating a completed project’s automation (no one is working on actively) and updating an in-progress automation (currently making changes).

The most difficult will likely be any Completed Project, as those automation scripts may not have anyone currently in the code-base. The tougher process for this case will likely be to get the time/budget to get these scripts updated so that they get back into working order. Assuming you can get over these initial hurdles, the actual work will be finding out where each change needs to be made to your code-base by debugging and seeing what is broken, then updating the locator calls each object that was affected.

In CodeScience’s case, we had used a practice of declaring these locators at the top of each object’s class as ‘public static By’ calls. This makes a quick way to locate and update the broken locators. If the script wasn’t written in such a way or was thrown together just to “get things working”, however, you may have a bit more difficulty doing the debugging and locating, but, the process is the same (fixing the locators).

If you are currently In-Progress with an automation script, then the “time/budget” shouldn’t be as big of an issue. The fixes will happen as part of the process of building the scripts. The process for updating these scripts would be the same as a completed project (debugging the failed tests and fixing the locators), just with the advantage of already knowing at least some of your code-base.

Then, as you write the new scripts, you would just use the new locators instead of the old ones. For these new builds (and for any new projects), I would highly recommend building a wrapper class for calls where you would pass a ‘By’ in the parameters and use the good-practices of keeping these locators in one area. This would help keep your code updates to as few places as possible so that you won’t have to dig through the code to find all your fixes in the future.

Looking Ahead

While changes to the DOM like this are not necessarily fun (especially when they break our automation scripts), these do happen, and we always need to have a basic maintenance to our code, anyway. Salesforce tries to not impact us too harshly with any changes, but in this case they didn’t have a different option. They have added a community page devoted to these changes and solutions, where you can find more detailed examples and solutions here.

Good luck, and happy coding!

CodeScience has helped build more than 10% of the apps on the AppExchange. Contact us today to learn how we can help your business thrive.