Post-Deployment User Testing in Salesforce

All Articles AI Culture Data Management Level 12 News Python Salesforce Software Development Testing

When deploying changes to Salesforce, it’s easy to assume that testing is a one-size-fits-all process. However, this assumption can lead to costly oversights.

The reality is that users interact with Salesforce in widely different ways depending on their roles and permissions. What works seamlessly for one user might create confusion or errors for another.

Why User Testing Is Essential in Salesforce

Salesforce is a highly customizable platform, therefore its functionality varies widely depending on user settings. For example:

  • A sales representative might have access to specific fields or features tailored to their role.
  • An administrator may see entirely different UI elements due to elevated permissions.
  • A manager might view dashboards and reports designed for oversight rather than execution.
  • An account executive might be limited in what they can view.

These variations mean changes to Salesforce—whether they involve new features, configuration updates, or bug fixes—can have vastly different impacts depending on who uses the system.

Testing in a vacuum (e.g., with a single user profile, usually your sys admin) doesn’t account for these differences.

Post-deployment user testing ensures changes work as intended across all relevant user archetypes. This approach helps you catch issues early, reduce downtime, and minimize end-user frustration.

How Permission Sets and Roles Shape the Salesforce Experience

Salesforce’s architecture is designed to enforce security and role-based access control. Users with different permission sets or roles may experience the platform differently. Here are a few examples:

1. Custom Permissions and Field-Level Security

Some users might have read-only access to certain fields, while others can edit or delete data.
Custom permissions can restrict or expand access to specific functionality (e.g., enabling/disabling buttons or tabs).

2. Role Hierarchy and Sharing Settings

Users in different roles may have varying levels of visibility into records based on sharing settings (e.g., private vs. public ownership).

A user’s position in the role hierarchy can affect how they interact with workflows, approvals, and escalations.

3. Profiles and User Interface Customization

Profiles dictate what a user can see and do within Salesforce. For example, one profile might allow users to create accounts, while another restricts them to editing existing records.

Custom UI elements (e.g., Lightning App Builder layouts) may appear differently depending on a user’s profile or permissions. (Note: Salesforce is deprecating profile-based permissions, but profiles still control many features, including page layouts).

4. Device, Page, and App Usage

Salesforce allows developers to create multiple apps within any given organization. These are terrific for siloing particular information or streamlining user access.

It also means the same data could be displayed very differently depending on where and how you view it.

Furthermore, the Salesforce mobile app has some striking differences from the desktop view that might be very important, particularly for sales reps on the go.

These differences highlight the importance of testing changes from multiple perspectives. A feature that works perfectly for an admin might break—or even go unnoticed—for end-users with limited access.

The Risks of Not Testing Across All User Archetypes

Failing to test across all relevant user archetypes can lead to a host of issues, including:

  • Broken functionality: Users in certain roles may encounter errors or dead ends when interacting with the system.
  • Data integrity problems: If field-level security or validation rules aren’t properly configured, users might enter incorrect data—or be locked out of necessary fields.
  • Missed features: End-users might not see critical updates or changes because their profiles or permissions prevent access to new functionality.

In addition to these technical challenges, inadequate testing can damage user trust and reduce adoption rates.

When end-users encounter unexpected issues, they’re less likely to embrace the platform as a valuable tool for their work.

How to Approach Post-Deployment User Testing

To ensure that your Salesforce changes meet the needs of all users, follow these best practices:

1. Identify Key User Archetypes

Before testing, map out the different roles and permission sets affected by your changes. For example:

  • Sales reps with standard profiles.
  • Managers with elevated permissions.
  • Support agents with limited access to certain records.

This exercise helps you prioritize which user archetypes need to be tested first.

2. Simulate Real-World Scenarios

Create test environments that mirror the actual Salesforce setup for each user archetype.

For example:

  • Test as a sales rep would, using their specific permissions and role hierarchy.
  • Test as an admin might, ensuring that new features align with their responsibilities.

3. Involve Stakeholders Early

Don’t wait until after deployment to involve end-users or stakeholders. Bring them into the testing process early so they can provide feedback and identify potential issues before they become critical.

4. Test Edge Cases and Boundary Conditions

Verify how users with minimal permissions interact with new features—and ensure that those with elevated access don’t inadvertently break functionality for others.

5. Iterate Based on Feedback

Be prepared to make adjustments based on user testing results. Even the most thoroughly planned changes can reveal unexpected issues once in production.

Testing from All Angles Ensures a Seamless Experience

Salesforce’s flexibility is one of its greatest strengths—but it also introduces complexity that must be carefully managed.

By prioritizing post-deployment user testing and accounting for the unique perspectives of all stakeholders, you can ensure that your changes deliver value to everyone who interacts with the platform.

Remember: testing isn’t just about verifying that something works—it’s about ensuring it works for everyone. By taking a holistic approach to user testing, you’ll foster trust, improve adoption rates, and create a more robust Salesforce environment for your organization.

Originally published on 2025-02-28 by Matthias Hager

Reach out to us to discuss your complex deployment needs (or to chat about Star Trek)