03.01.03 — Defining Users Correctly in Salesforce Test Cases

Lesson goal

This lesson explains how to define users correctly in Salesforce test cases and why user definition is a common source of false test results.

After this lesson, you should understand:

• why users in test cases represent permission context, not people,
• how incorrect user definitions invalidate test coverage,
• How to define users in a way that survives environment changes.

Why user definition is critical in Salesforce testing

In Salesforce, user context controls behaviour more than almost anything else.

The same action performed by two different users may result in:

• different field visibility,
• different validation behaviour,
• different automation execution,
• different access to records.

If the user is defined incorrectly, the test case becomes meaningless.

A user is not a person

One of the most common mistakes in Salesforce test cases is defining users as people.

Examples:

• “John Smith”
• “Test User 1”
• “Sales User A”

These definitions do not describe behaviour.

They describe identity.

Identity is irrelevant in Salesforce testing.

What a user actually represents

In a test case, a user represents a permission context, composed of:

• profile
• permission sets
• role hierarchy position
• sharing access
• custom permissions

Together, these elements define what the system allows the user to do.

A correct user definition makes this context explicit.

Why named users break test cases

Named users create several problems:

• they differ between environments,
• they disappear after sandbox refreshes,
• they accumulate unintended permissions over time,
• Their configuration is rarely reviewed.

As a result:

• tests pass in one org and fail in another,
• execution depends on tribal knowledge,
• Defects are misclassified as environmental issues.

Defining users by capability, not identity

A correct user definition answers one question:

What is this user allowed to do in the context of this test?

Instead of:

User: Test User 1

Use:

User: Sales Representative with standard Sales profile, no additional permission sets, access limited to own Accounts

This definition:

• is portable,
• is reviewable,
• is executable by anyone.

Profiles alone are not enough

Many test cases define users solely by their profiles.

This is often insufficient.

In real Salesforce projects:

• permission sets extend profiles,
• custom permissions override defaults,
• Automation may check for specific permissions.

User definitions must include all relevant access modifiers, not just profile names.

Admin users and false confidence

Testing as a System Administrator hides problems.

Admin users:

• bypass validation rules,
• ignore sharing restrictions,
• see all fields,
• can perform actions blocked for business users.

Using Admin as a default test user:

• invalidates permission coverage,
• hides configuration defects,
• creates false confidence in test results.

Rule:

If a feature is meant for business users, it must never be tested as Admin.

When Admin users are acceptable

Admin users are acceptable only when:

• testing admin-only configuration,
• validating setup behaviour,
• performing environment preparation.

They should not be used for:

• functional business testing,
• UAT preparation,
• regression of business flows.

User definition and test intent

User definitions should align with test intent.

If the test verifies:

• permissions → user definition must be explicit
• business process → user must reflect real actor
• error handling → user must be capable of triggering the error

Vague user definitions lead to vague test results.

Common user definition anti-patterns

Frequent mistakes include:

• relying on “any sales user”,
• assuming default permissions,
• skipping role and sharing context,
• mixing admin and business users.

Each of these reduces test reliability.

Key takeaway

• Users in test cases represent permission context, not people.
• Named users make test cases fragile.
• Profiles alone are rarely sufficient.
• Admin users hide defects and invalidate coverage.

Correct user definitions are the foundation of reliable Salesforce test cases.