Impersonating Salesforce users in test frameworks

A guide to executing automated tests with any profile needed

Thales Oliveira
Sep 30, 2020 · 5 min read
Photo by Finan Akbar on Unsplash

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:

  1. Login into Salesforce using an Admin user;

The parameters required in this URL are:

  • oid: Organization 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.

Apps available on an Organization.


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;

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 -H "Authorization: Bearer token"

or by inspecting the App’s options.

Inspect the TSID menu.

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.

Implementation of the App enum.
Implementation of the App enum.

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.

Salesforce page showing the Profiles in the Organization.
Salesforce page showing the Profiles in the Organization.
Profiles in the Organization.
Implementation of the Profile enum.
Implementation of the Profile enum.

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.

Implementation of the Impersonate command.


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.

Smartbox engineering

Smartbox engineers sharing their experiences, failures, and…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store