04.02.02 — CRUD Testing on Salesforce Objects

Lesson goal

This lesson explains how to test CRUD permissions in Salesforce correctly, focusing on effective access rather than configuration assumptions.

After completing this lesson, you should be able to:

• design CRUD test cases for Salesforce objects
• validate access across Profiles, Permission Sets, and Sharing Rules
• identify high-risk CRUD misconfigurations before production
• apply the Access Matrix in real testing scenarios

This lesson builds directly on 04.02.01 — Profiles vs Permission Sets and applies security theory to executable test cases.

The problem: access control is the highest risk

CRUD (Create, Read, Update, Delete) testing is the foundation of Salesforce security validation.

Every Salesforce implementation relies on layered access control:

• Profiles
• Permission Sets and Permission Set Groups
• Organization-Wide Defaults (OWD)
• Sharing Rules
• Record ownership

A single misconfiguration in any layer can result in:

• unauthorized data access
• silent data corruption
• irreversible data loss

Because access is calculated dynamically, CRUD tests that pass in one Sandbox may fail in another if effective permissions are not tested explicitly.

CRUD testing as a matrix problem

CRUD testing is not performed per object or per user in isolation.
It must be executed against an Access Matrix:

User role × Object × CRUD operation

Every intersection in this matrix represents a mandatory test case.

If a role exists in the system, and an object exists in the data model, CRUD behavior must be validated for that combination.

Read (R): record visibility and field-level access

Read testing verifies:

• whether a user can see a record at all
• which fields are visible or hidden (FLS)

Positive read test

• Precondition: User is the record owner or has access via Sharing Rules or Role Hierarchy.
• Action: Open the record directly or access it via a list view or report.
• Expected result:
  The record is visible and loads successfully.

Negative read test

• Precondition: User has no access via ownership, role hierarchy, or sharing.
• Action: Attempt to access the record via direct URL or reporting.
• Expected result:
  The record is not visible, or Salesforce returns an Insufficient Privileges error.

Read testing must always include field-level security validation, not only record visibility.

Create (C): record creation and initialization

Create testing validates:

• whether the user can initiate record creation
• whether system defaults and automation execute correctly

Create test focus

• Action: Click New and attempt to save a record.
• Verification points:
• available Record Types
• default field values
• required field enforcement
• before-save Flows or automation logic

Create access is often granted too broadly and must be tested per role.

Update (U): editing rights and record state

Update testing combines:

• object-level permissions
• field-level security
• record state logic

Positive update test

• Precondition: User has Update permission on the object.
• Action: Edit the record.
• Expected result:
  Editable fields behave as expected, restricted fields remain read-only.

Negative update test

Update denial often occurs due to business rules, not object permissions.

Common scenarios:

• closed Opportunities
• records under Approval Processes
• lifecycle-based locks
• Action: Attempt to edit or save changes.
• Expected result:
  Edit is blocked via hidden buttons, validation errors, or system messages.

Delete (D): permanent and cascading effects

Delete testing is high-risk because it can remove data permanently.

Positive delete test

• Precondition: User has Delete permission.
• Action: Delete the record.
• Verification:
• record moves to Recycle Bin or is permanently deleted
• cascading deletes execute correctly in Master-Detail relationships

Negative delete test

• Precondition: Delete permission is denied.
• Action: Attempt to delete the record.
• Expected result:
  Delete action is blocked or returns Insufficient Privileges.

Delete access must always be validated explicitly, never assumed.

CRUD testing and record ownership

Many CRUD outcomes depend on ownership, not just permissions.

Ownership-based test

• Precondition: User has Update permission on the object, but Read-Only access via Sharing Rules.
• Action: Attempt to edit a record owned by another user.
• Expected result:
  The record is visible but cannot be modified.

This test validates that the Sharing Model correctly restricts CRUD based on ownership context.

Practical QA strategy: negative-first testing

For security validation, negative tests are more valuable than positive ones.

Best practice:

• first prove that access is correctly denied
• then verify that required access is granted explicitly

This approach prevents false confidence caused by permissive test environments.

Summary

CRUD testing is the core of Salesforce security validation.

From a QA perspective:

• CRUD must be tested per role, not per object
• effective permissions matter more than configuration
• denial paths are as important as execution paths

By systematically applying CRUD tests across the Access Matrix, QA ensures that Salesforce enforces least privilege, protects business data, and behaves predictably across environments.

What’s next

Next, we expand security testing into data ownership and sharing logic:
04.02.03 — Sharing Rules, OWD, and Record Ownership