By Tomasz Teodorowicz — 31 Dec 2025

03.04.04 — CRUD Testing & Permissions: Access Matrix

Lesson goal

This lesson explains how to design and execute CRUD and permission-based testing in Salesforce using an access matrix approach.

After this lesson, you should be able to:

systematically validate Create, Read, Update, and Delete permissions,
identify gaps in configuration-based security,
design permission tests that scale with complex Salesforce implementations.

Why permissions testing is critical in Salesforce

Salesforce is fundamentally a data access platform.

Almost every functional defect in Salesforce can be traced back to one of two issues:

incorrect business logic,
incorrect access control.

Permissions determine:

who can see data,
who can modify data,
who can trigger automation,
who can bypass restrictions.

Testing functionality without testing permissions creates a false sense of quality.

What CRUD testing really means in Salesforce

CRUD stands for:

Create
Read
Update
Delete

In Salesforce, CRUD permissions are enforced at multiple levels:

object level,
field level (FLS),
record level (sharing),
process level (automation and approvals).

A user may:

see a record but not edit it,
edit some fields but not others,
trigger automation but not delete the record.

Each combination represents a distinct behavior path.

The Access Matrix concept

An access matrix maps:

actors (users or roles)
against actions (CRUD operations)
on objects and fields

The matrix answers a simple question:

Can this actor perform this action on this data?

Without a matrix:

permission coverage is accidental,
tests are duplicated or missed,
defects appear late in UAT or production.

Defining actors for the matrix

Actors should be defined by:

profile,
permission sets,
role and sharing context,
special permissions (custom permissions, feature access).

Actors are permission contexts, not individual users.

Example actors:

Sales Representative
Sales Manager
Support Agent
Read-Only User

Each actor represents a unique access profile.

Defining actions and scope

For each actor, define:

Create permissions on objects,
Read access to records,
Update permissions on objects and fields,
Delete permissions and constraints.

Scope should include:

standard objects,
custom objects,
critical fields,
sensitive data.

Do not attempt to test everything.

Focus on business-critical access paths.

Field-level security in CRUD testing

Field-level security often hides defects.

Examples include:

fields visible but not editable,
fields editable but ignored on save,
hidden fields still required by validation rules.

Test cases must verify:

visibility,
editability,
system behavior on save.

Field-level access must be tested together with object-level permissions.

Record access depends on:

ownership,
role hierarchy,
sharing rules,
manual sharing.

CRUD tests should include:

own records,
shared records,
non-shared records.

Many permission defects only appear when testing non-owned data.

Permissions and automation side effects

Permissions influence automation behavior.

Examples:

flows triggered only for certain users,
approval submission blocked by permissions,
automation updating fields invisible to the user.

Test cases should verify:

whether automation executes,
whether results are visible,
whether permissions block or allow side effects.

Ignoring this creates partial coverage.

Negative testing vs error injection

Classic negative testing (trying random invalid actions) is inefficient in Salesforce.

Instead, focus on error and permission injection:

attempt forbidden actions intentionally,
force validation failures,
trigger permission boundaries.

This approach:

validates enforcement,
reduces test count,
focuses on real risk.

Maintaining the access matrix

Access matrices must evolve with the system.

When:

new roles are added,
permissions change,
objects are extended,

the matrix should be updated first.

Test cases should reference the matrix, not duplicate permission logic.

Common CRUD testing mistakes

Frequent issues include:

testing only happy paths,
ignoring Delete permissions,
testing only Admin users,
separating permission tests from functional tests.

Permissions are not a separate test area.

They are part of functional behavior.

Key takeaway

CRUD and permission testing is core Salesforce QA work.
An access matrix provides structure and coverage.
Actors represent permission contexts, not users.
Field-level and record-level access must be tested together.
Error injection is more effective than random negative testing.

Without systematic permission testing, Salesforce quality cannot be trusted.