Salesforce - Automation pitfalls

Salesforce has a couple of common pitfalls. These pitfalls are not specific to an automation tool. Both no/low code and high coding tools and different test frameworks need to handle these pitfalls and can benefit from the tips below to create a stable test framework. A good way to avoid the GUI is to use the Salesforce API's.

The API support, both REST and SOAP can be used to create or modify data. SOQL (Salesforce Object Query Language) queries can also be created this way. In Trailheads, there are several training modules where you can learn how to connect API to your ORG (Salesforce sandbox/ environment) and how to use it. Trailheads also offer trails about SOQL, the difference between SOQL and SQL. And how to write a good query.

You can also use chrome add-ons or tools to make it easier to use. For example, “Salesforce Inspector” or “Maven Tools for Salesforce”. Both are directly connected to your Salesforce ORG and can handle both metadata and object data. 

The tips listed below can be used to avoid the common automation pitfalls:

  • Create paths to the web element yourself and identify the correct attribute to use. An ID-attribute for example will generate a random number/code with every refresh and deployment. So ID’s cannot be used in locators. 
  • Build paths to the web element via the label to the specific and attached text field. If the field's position changes (due to the page layout changes), the path is still valid because the label and the field are always attached to each other. Don't make paths like “div/div/div/lightning-formatted-text”.  
    In this example, the locator is using the text of the label object and from there it navigates to the first formatted text. This is always the field where the, for example “Account Name” is stored. These two fields will always be together, so also changing the page layout will not affect this xpath. 



  • For common Salesforce objects like spinners, look for the attributes that the objects have in common to make a generic function for it. For example spinners have a spinner container class. This is common for all spinners, regardless of the size of the spinner. All spinners can be handled in the same manner.  


     The red outlined class is common for all spinners, so this can be used in the xpath. The function “waitForSpinnerToAppear()” waits for this element to be visible. The yellow outlined class cannot be used, because in this case it’s a “spinner--medium”, but the other spinners can have a class with “spinner--small”.

  • Identify the iframes and make sure to switch to the specific iframe before executing tests in an iframe, or switch to the main frame and refresh the page to clean up iframe cache. 
  • Search in the Document Object Model (DOM) for dropdown options, they are always located at the bottom of the DOM in a dropdown container, not in the actual dropdown element. 
  • Use different ways to identify an object or get information from an object. If for example Selenium can't get the text of an element, because it’s a calculated field, and populated based on database information that is fetched during execution. Try using Javascript to get the “innertext” of the object. 
  • Scroll down to the end of the page before searching for certain elements, the page and its components are only loaded at request. So, with every scroll down, new elements and components are loaded. Make use of this knowledge and make sure your page is fully loaded and ready. 
    A “scrollTillEndOfPage()” function can take care of this pitfall. First you need to get the height of the page. Then, you need to know at what position you are located on the page and the length of the scrollbar. With that knowledge, you can build a while loop to scroll down, for example 1000 pixels at a time until you are at the bottom. While updating your new location every scroll., as long as you are not at the bottom, you can keep scrolling. When you reach the end, you can break out the loop and scroll back up to the page to start the actual test. All the elements are now loaded and can be found.


Building Blocks

Quality Engineering within Salesforce

Quality Assurance

Automated Testing

People involved



Related wiki's

   Look and feel 

    Automation pitfalls 

   Architecture and Releases  

   SuccessFactors explained