Impersonating Salesforce users in test frameworks
A guide to executing automated tests with any profile needed
Profiles define the permissions users have when accessing objects and data, and how they can interact with an application. When creating test scenarios for systems that allow multiple profiles, it’s important to make sure the correct one is used in the execution.
In Salesforce, it’s possible to have several profiles and assign one of them to users across the organization. The problem is that having a user for each desired profile, only for testing purposes, can be a bit pricey and the company you work for may not be interested in paying for that. Luckily, Salesforce allows Administrators to impersonate existing users that already exists in the sandbox.
By the end of this article you will be able to impersonate users in Salesforce on a test automation framework. The implementation will be in Cypress, but it’s reproducible to any other language or platform. In case you want to know more about tests in Salesforce using Cypress, refer to this other article I wrote on this topic.
What does it take to login with a different user?
User impersonations can be done through two different ways in Salesforce: by accessing the User’s page and clicking the “Login” button or by adding some parameters to your domain’s URL. However, it’s not recommended to use the UI for this in an automation framework, as it would be time-consuming. So, let’s do it by following these two steps:
- Login into Salesforce using an Admin user;
- Access
https://mysandbox.salesforce.com/servlet/servlet.su?oid=ORGANIZATION_ID&suorgadminid=USER_ID&targeURL=/home/home.jsp?tsid=APP_ID.
The parameters required in this URL are:
- oid: Organization Id;
- suorgadminid: Id of user to be impersonated;
- targetURL: Path to the page to be opened;
- tsid (optional): App Id or Tab Set Id.
The Organization Id is the unique identifier for your Salesforce instance. It’s important to know that the Organization ID of the production environment is different than your Sandbox Organization ID. Also, whenever a Sandbox is refreshed, a new ID is established.
The Tab Set Id (tsid) represents the App the User will access. An App is a collection of items that work together to serve a particular function. In other words, it’s a group of tabs put together to provide certain functionality. Users can check and switch apps by using the drop-down menu on the top-right corner of the pages.
Implementation
Having this in mind, we can start making considerations about the automation strategy. First, let’s talk about the implementation of two different approaches:
- Hard-code the parameter values;
- Query the parameter values every time a test scenario is executed.
Honestly, both approaches have pros and cons, depending on the reality of your project. The first one runs faster. However, it can increase the flakiness, and the maintainability time in case there’s no control over the modifications made to the sandbox’s data. On the other hand, the second one is relatively slower, but its implementation doesn’t require code modifications when a specific user is changed or the sandbox is refreshed, for example.
In this article, the approach chosen was the one that will free us from unexpected failures in case of changes in the Sandbox. If you want to follow the hard-coded approach, replace the values obtained from the database.
We will start by getting the TSID’s available in the Sandbox. They can be found either by using the command
curl https://yourInstance.salesforce.com/services/data/v29.0/appMenu/ -H "Authorization: Bearer token"or by inspecting the App’s options.
Now, let’s implement two “enums”. The first one represents the TSID’s. Have in mind that the names and values will vary according to your Organization.
The second enum represents the Profiles we want to impersonate. To view the profiles in your Organization, from Setup, enter “Profiles” in the Quick Find box, then select Profiles. The value used in the example is the Profile Name.
Finally, we need to create a command to impersonate the user. This command will receive the Profile Name as a parameter.
The TSID (App View) will be defined according to the Profile, that is, each Profile will open in a specific view.
The Organization Id and the User will be obtained through a SOQL query. You can add as many restrictions as you need. In this case, the only things checked are whether the user is active and has a Manager. In case you don’t know how to query in Salesforce using Cypress, refer to this other article I wrote on the topic.
All we need to do now is to assemble the URL we’re going to use, then visit it. The command can be used anywhere in your code but keep in mind that it can only be called after login in into Salesforce.
Conclusion
User impersonation can be a useful strategy when you’re building a test automation framework in Salesforce. It can save the company money and provides more flexibility to your testing as it won’t be required to manage multiple users and credentials in the framework.
If you have different strategies, suggestions, or difficulties, feel free leave comment. We may be able to help each other.
