Salesforce Security Testing Across Every User and Process
Salesforce security testing is the functional validation of who can do what in your org. SyntraFlow is designed to confirm that users, integrations and agents can perform exactly the actions they are authorised to perform — and nothing more — across profiles, permission sets, object and field access, record sharing and every layer in between.
Access validation for Salesforce teams that treat permissions as a testable requirement — available today for demonstration and proof-of-concept validation alongside SyntraFlow's established Oracle foundation.
Why Salesforce access is hard to validate
Salesforce access is not a single switch. It is the combined result of profiles, permission sets, permission-set groups, object and field settings, sharing rules, role hierarchy and restriction rules — each layer capable of granting or withholding access on its own. What a given user can actually see and do is an emergent outcome of all of them at once, and that outcome is exactly what needs to be tested.
Access is layered and cumulative
A user's effective access is the sum of a profile and every assigned permission set and group. Reading the settings one screen at a time rarely reveals what the combination actually permits.
The riskiest failure is silent
Over-provisioning does not throw an error. A field left visible or an object left editable simply works, so the failure is invisible until an audit, an incident or a data-exposure review finds it.
Sharing depends on real records
Record-level access is driven by ownership, role hierarchy and sharing rules against live data. You cannot judge it from configuration alone — it has to be exercised with representative records and personas.
Every change can move a boundary
A new field, an edited permission set or a seasonal platform release can quietly widen or narrow access. Without regression, access correct last month may not be correct today.
Non-human identities count too
Integration users, guest users and automated processes have their own access footprint — often broad, often forgotten — and each one is a path into your data that deserves the same scrutiny as a human user.
"Nothing more" is rarely tested
Teams routinely confirm that a user can do their job. Far fewer confirm the equally important half of the requirement: that the same user cannot do what they should not.
What security testing means here
This page is about functional access validation: proving, through repeatable tests, that the right identity gets exactly the right access to the right records and fields — and is blocked everywhere else. It is a behaviour-verification discipline, closely related to the way permission differences are surfaced in Salesforce metadata intelligence and then confirmed against live personas here.
It is deliberately not a replacement for the platform and tooling that enforce and monitor security. Salesforce Shield, Security Center, Event Monitoring, code scanning, static application security testing (SAST) and third-party penetration testing and identity-governance platforms each do a distinct job — encryption, threat monitoring, vulnerability discovery, code analysis and identity lifecycle. SyntraFlow is designed to complement them by answering a narrower, testable question they do not: does the configured access actually behave the way it is supposed to for every user, integration and process?
The core requirement in one line
Confirm that users, integrations and agents can perform exactly the actions they are authorised to perform — and nothing more. Everything on this page is a way of turning that single sentence into concrete, re-runnable tests.
Profiles, permission sets and permission-set groups
Modern Salesforce access is built on a permission-set-led model. Understanding how these building blocks combine is the starting point for testing them, because access testing is really about validating the effective result once every grant is layered together.
Profiles
Every user has exactly one profile, which sets baseline defaults such as login hours, default record types and a floor of permissions. Salesforce guidance now favours keeping profiles lean and granting most access through permission sets.
Permission sets
Permission sets grant additional, composable access on top of the profile without changing it. A user can hold many, and access is additive — permission sets grant, they do not revoke what a profile already allows.
Permission-set groups
Permission-set groups bundle several permission sets into a role-shaped package, with muting to trim specific permissions back out. The bundle plus its mutings must be tested as a whole, because the net effect is not obvious from any single set.
Because these grants stack, the only reliable way to know a user's access is to evaluate them together as a persona and then verify that persona's real behaviour in the org. That persona-based evaluation is the throughline of every layer described below.
The layers of Salesforce access to validate
Each layer controls a different dimension of access, and each needs its own positive and negative checks. SyntraFlow is designed to exercise these layers as a connected whole, so a persona is validated end to end rather than one setting at a time.
| Access layer | What it controls | What to validate |
|---|---|---|
| Object-level access | Create, read, edit and delete on each object, plus View All and Modify All. | Each persona has exactly the CRUD it needs on each object, and no unexpected View All or Modify All. |
| Field-level security | Whether a field is visible and editable for a given persona. | Sensitive fields are hidden or read-only where required, and remain so after new fields ship. |
| Record-level sharing | Which specific records a user can see, via org-wide defaults, ownership and sharing rules. | Users see the records they should and are blocked from records owned by others outside their scope. |
| Role hierarchy | Upward visibility — managers inheriting access to records owned by people below them. | A manager sees a subordinate's records, and a peer at the same level does not. |
| Restriction rules | A further filter that narrows which accessible records a user may actually see. | The rule tightens visibility as intended without hiding records users legitimately need. |
| Experience Cloud & guest access | What external and unauthenticated users can reach through a site or portal. | Guest and community users see only what is intended and never reach internal data. |
| Integration-user access | The objects, fields and records an API or automation identity can act on. | The integration can do its job and is scoped down from broad, standing admin-level rights. |
The access-validation workflow
Security testing works best as a repeatable sequence that turns your intended access policy into evidence. Each step is designed to build on the last, so a run ends with a clear record of who can do what — and proof that no one can do more.
Define the personas that matter
Identify the human roles, integration users and guest contexts that represent real access in your org — sales rep, service agent, ops manager, portal visitor, API identity — each with the access it is supposed to have.
State the intended access
For each persona, capture what should be allowed and what should be denied, at the object, field and record level. This intended-access baseline is the specification every test is measured against.
Resolve effective access
Combine the profile, permission sets and permission-set groups for each persona to determine effective access, so tests target the real cumulative result rather than any single setting.
Run positive access tests
Confirm each persona can perform every action it is entitled to — open the record, edit the field, run the process — so legitimate work is never blocked by an over-tightened policy.
Run negative access tests
Confirm each persona is blocked from everything it should not reach — the hidden field, the other team's records, the restricted object — proving the "and nothing more" half of the requirement.
Exercise record-level sharing
Using representative records, verify that ownership, role hierarchy, sharing rules and restriction rules combine to expose exactly the right rows to each persona and no others.
Record the evidence
Capture each persona, action, expected outcome and actual result as durable evidence, so the state of access can be shown to reviewers and auditors rather than described from memory.
Re-run as a regression suite
Turn the whole set into a regression pack that runs after each change and each seasonal release, so access boundaries are re-proven every time the org moves. This feeds directly into Salesforce test automation.
Security testing capabilities
These are the capabilities SyntraFlow is designed to provide for Salesforce access validation. They are available today for demonstration and proof-of-concept validation as the Salesforce vertical matures alongside SyntraFlow's established Oracle foundation.
Persona-based access testing
Designed to run tests as a defined persona — a specific combination of profile, permission sets and groups — so results reflect what a real user, not an administrator, can actually do. Why it matters: effective access is what gets audited.
Object-level access validation
Designed to verify create, read, edit and delete plus View All and Modify All on each object for every persona. Salesforce components: object permissions on profiles and permission sets. Benefit: catch over-broad object rights before they ship.
Field-level security validation
Designed to confirm that sensitive fields are hidden or read-only for the right personas across page layouts, reports and APIs. Components: field-level security. Benefit: keep compensation, PII and financial fields out of the wrong hands.
Record-level sharing validation
Designed to test that org-wide defaults, ownership and sharing rules expose the correct records to each persona. Components: OWD, sharing rules, manual and criteria sharing. Benefit: prove data isolation between teams, regions or clients.
Role-hierarchy validation
Designed to confirm that upward visibility flows exactly as the hierarchy intends. Components: role hierarchy and "grant access using hierarchies". Benefit: managers see their teams' work while peers stay isolated.
Restriction-rule validation
Designed to verify that restriction rules narrow visibility as intended without hiding records users legitimately need. Components: restriction rules. Benefit: enforce need-to-know without breaking day-to-day work.
Experience Cloud & guest-user testing
Designed to validate what external and unauthenticated visitors can reach. Components: guest user profile, sharing sets, Experience Cloud site settings. Benefit: prevent public exposure of internal objects and records.
Integration-user validation
Designed to test the scope of API and automation identities so they do only their job. Components: integration user profiles, connected apps, named credentials. Benefit: shrink standing, broad service-account access.
Negative access testing
Designed to assert that each persona is denied everything outside its scope. Components: all access layers, tested for the deny case. Benefit: prove the "nothing more" half of every access requirement.
Segregation-of-duties checks
Designed to detect personas that combine conflicting capabilities — for example creating and approving the same record. Components: permission combinations across sets and groups. Benefit: support internal-control and compliance requirements.
Security regression suites
Designed to re-run the full access suite after each metadata change and seasonal release. Components: the persona and access-rule library. Benefit: catch access drift the moment a change introduces it.
Audit-ready access evidence
Designed to retain each test, expected outcome and result as durable evidence. Components: the run history and persona definitions. Benefit: answer "who can access this?" with proof, not assertion. See SyntraFlow security.
The access paths teams forget
Internal human users usually get the most attention, but the highest-risk access often sits with external visitors, service accounts and the deny cases nobody wrote a test for. Each of these deserves first-class validation.
Experience Cloud & guest users
Public sites and portals expose a guest-user context that can reach far more than intended if sharing sets and object settings are loose. Testing here confirms that unauthenticated visitors see only the records and fields a site is meant to publish — and nothing behind the login wall.
Integration and API users
Service accounts that move data between systems often accumulate broad, standing access because it is convenient. Validation confirms an integration identity can perform its specific operations and is otherwise scoped down, so a compromised credential cannot roam the whole org.
Negative access and least privilege
Negative testing is where over-provisioning is caught. By deliberately attempting the actions each persona should be denied, you turn "least privilege" from an aspiration into a set of passing tests that fail loudly the day a boundary slips.
Security regression after change and release
Access is never validated once. A single new field defaults into field-level security decisions, an edited permission set ripples across everyone who holds it, and each seasonal Salesforce release — Spring, Summer and Winter — can adjust platform behaviour that touches sharing and visibility. Any of these can move a boundary that was correct yesterday.
The practical answer is a security regression suite: the persona-and-access library from your validation workflow, re-run on a schedule and on every change. When Salesforce metadata intelligence flags that a permission set, profile or sharing rule changed, that signal is designed to trigger the exact access tests affected — a targeted re-check rather than a blanket re-run.
Because Salesforce previews each seasonal release in sandbox ahead of production, the same access suite can run against the preview org first, so any change to visibility or sharing behaviour is caught before it reaches live users. Pairing this cadence with automated execution keeps access boundaries continuously proven rather than periodically assumed.
Agentforce access and action boundaries
Salesforce AI agents run as a user and are expected to honour that user's object, field and record access — but agents surface data through reasoning, retrieval and actions in ways a static page does not, so their access boundaries need their own dedicated testing rather than being assumed from platform settings.
Agent-specific security — persona inheritance in practice, action scope, data-leakage and prompt-injection resistance — is covered in depth on the Agentforce testing practice and its focused agent security guide; this page stays on general platform and user-access validation.
Authorisation rarely stops at Salesforce
The same person who can only see their own accounts in Salesforce may, through an integration, be able to read far more once data lands in Oracle, SAP, Workday or NetSuite. Access controls are enforced separately in each system, and a boundary that holds in Salesforce can quietly reopen on the other side of an integration. Testing one platform in isolation misses exactly this class of exposure.
This is where SyntraFlow's heritage matters. Access validation is designed to follow a transaction across the boundary — confirming that when a Salesforce identity or integration user pushes data into a connected back-office system, the receiving system applies its own authorisation correctly and the combined path grants no more than intended. Segregation of duties, in particular, is often a cross-system property: create in one platform, approve in another.
That cross-application view is the same authorisation-intelligence discipline SyntraFlow has long applied on the Oracle side, where validating who can do what across interconnected modules is core to safe operations. Salesforce security testing brings that sister approach to the front office, so a single access review can span both platforms rather than one at a time.
Explore the connected-system perspective on the Oracle ERP testing tool, which applies authorisation and controls testing to Oracle environments and pairs naturally with Salesforce security testing for organisations running both.
Explore each area of security testing
Salesforce security testing spans several focused disciplines. The following areas go deeper into specific access layers and validation workflows, and are being expanded as dedicated guides.
Permission set testing
Validate the access granted by permission sets and permission-set groups, including muting.
Field-level security testing
Confirm sensitive fields are hidden or read-only for the personas that should not see them.
Sharing rule testing
Test org-wide defaults and sharing rules so record visibility matches intent.
Role hierarchy testing
Verify upward visibility so managers see their teams' records and peers stay isolated.
Experience Cloud security testing
Validate what community and portal users can reach across an Experience Cloud site.
Integration user testing
Confirm API and automation identities are scoped to exactly what they need.
Security regression testing
Re-prove access boundaries after every metadata change and seasonal release.
Segregation of duties
Detect personas that combine conflicting capabilities across sets and groups.
Profile permission testing
Validate the baseline access a profile grants before permission sets are layered on.
Restriction rule testing
Confirm restriction rules narrow visibility without hiding needed records.
Guest user security testing
Test the unauthenticated guest-user context for public sites and portals.
Negative access testing
Assert the deny cases so over-provisioning fails a test instead of an audit.
Outcomes
Security testing is designed to move a Salesforce team from assuming access is correct to being able to prove it — for every user, integration and process, on demand.
Least privilege you can prove
Positive and negative tests together demonstrate that each identity has exactly the access it needs and no more, turning least privilege into a passing suite rather than a policy statement.
Fewer data-exposure surprises
Validating field-level security, sharing and guest access before release catches the silent over-provisioning that would otherwise surface in an incident or audit.
Confidence through every release
Re-running the access suite after each change and seasonal release means boundaries are continuously re-proven, so security keeps pace with a moving org.
Audit evidence on demand
A durable record of personas, actions and results answers reviewer and auditor questions with proof, and pairs with the wider SyntraFlow security control framework.
Security testing works closely with Salesforce metadata intelligence and the wider Salesforce testing practice to keep access correct across every environment.
Salesforce Security Testing FAQs
What is Salesforce security testing?
Salesforce security testing is the functional validation of access behaviour — confirming that each user, integration and agent can perform exactly the actions they are authorised to perform, and nothing more. It exercises profiles, permission sets, object and field access, record sharing, role hierarchy and restriction rules as a connected whole, using real personas rather than reading settings screen by screen.
Does SyntraFlow replace Salesforce Shield or penetration testing?
No. Salesforce Shield, Security Center, Event Monitoring, code scanning, SAST, penetration testing and identity-governance platforms each handle encryption, monitoring, vulnerability discovery and identity lifecycle. SyntraFlow is designed to complement them by answering a different, testable question: does the configured access actually behave as intended for every user and process? It is access validation, not a security-enforcement or vulnerability-scanning tool.
What is the difference between profiles and permission sets?
Every user has exactly one profile, which sets baseline defaults and a floor of permissions. Permission sets grant additional, composable access on top of the profile, and a user can hold many. Access is additive — permission sets grant rather than revoke — so a user's real access is the combined effect of the profile and every assigned permission set and group, which is exactly what testing evaluates.
What is negative access testing and why does it matter?
Negative access testing deliberately attempts the actions a persona should be denied — opening a hidden field, editing another team's record, reaching a restricted object — and passes only when access is correctly blocked. It matters because over-provisioning is silent: an unauthorised action that simply works produces no error, so without negative tests the failure stays invisible until an audit or incident.
How do you test record-level sharing?
Record-level access depends on ownership, org-wide defaults, role hierarchy and sharing rules against live data, so it cannot be judged from configuration alone. Testing uses representative records and personas to confirm each user sees exactly the rows they should and is blocked from the rest — for example verifying a manager sees a subordinate's records while a peer at the same level does not.
Can integration and guest users be tested the same way?
Yes, and they should be. Integration users, API identities and Experience Cloud guest users each have their own access footprint that is often broad and easy to overlook. SyntraFlow is designed to validate these non-human and external contexts as first-class personas, confirming an integration can do its job and is otherwise scoped down, and that guest visitors reach only what a public site intends to publish.
How is security regression handled after a Salesforce release?
The persona-and-access library from your validation workflow becomes a regression suite that re-runs after each metadata change and each seasonal release — Spring, Summer and Winter. When a permission set, profile or sharing rule changes, that signal is designed to trigger the specific access tests affected, and because Salesforce previews releases in sandbox first, the suite can run against the preview org before changes reach production.
Does this cover Agentforce agent security?
This page covers general Salesforce platform and user-access validation. AI agents run as a user and are expected to honour that user's access, but agent-specific security — action scope, data-leakage and prompt-injection resistance — needs its own dedicated testing, covered on the Agentforce testing practice rather than duplicated here.
Prove exactly who can access what
Bring functional access validation to your next Salesforce release. Test every persona, integration and boundary — and turn least privilege into a suite you can re-run on demand.