Salesforce Segregation of Duties Testing
Salesforce segregation of duties testing identifies personas whose combined access lets one person complete a sensitive process end to end — create and approve, request and fulfil, grant and use — and then proves in the org whether that combination is actually possible. SyntraFlow is designed to evaluate conflicts across profiles, permission sets and permission set groups, and to confirm controls hold when a real persona tries to act.
A segregation of duties conflict is rarely one bad permission. It is two reasonable permissions held by the same user.
Why segregation of duties is hard in Salesforce
Segregation of duties is a familiar control in ERP systems, where purchasing, payables and vendor maintenance are separated by design. In Salesforce the same principle applies to discount approval, commission adjustments, refunds and credits, contract activation and administrative access — but the access model makes conflicts harder to see.
A user's effective access is the union of one profile and every assigned permission set, including those bundled into permission set groups. Muting permission sets can remove specific permissions from a group, but only within that group; another group or a directly assigned set can grant the same permission back. Two groups that each look well designed can therefore combine into a toxic pairing for the few users who hold both, and a review of either group alone will never show it.
Conflicts also exist outside permissions. An approval process may allow a submitter to be their own approver through a queue or a related user field. A Flow running in system context may perform an action the user could not perform directly. And administrative permissions such as Manage Users or Assign Permission Sets let a user grant themselves any capability they lack. Testing has to consider all of these paths, which is what separates it from reviewing permission set testing results one set at a time.
Example conflict pairs to define and test
Conflict rules are specific to each business. These examples show the pattern: two capabilities that should not meet in one persona.
| Capability A | Capability B | Risk if one user holds both |
|---|---|---|
| Create or edit quotes and discounts | Approve discounts above threshold | A user can grant and approve their own excessive discount. |
| Edit commission or incentive records | Close opportunities as won | A user can influence both the deal outcome and their own payout. |
| Create refund or credit cases | Approve or process refunds | A user can raise and release a refund without independent review. |
| Edit account bank or billing details | Initiate invoices or payment requests | A user can redirect payments without a second person seeing the change. |
| Manage Users or Assign Permission Sets | Any business capability | A user can escalate their own access to bypass every other separation. |
| Author Apex or Customize Application in production | Approve change or deployment records | A user can build and sign off their own production change. |
| Activate contracts | Edit contract pricing terms | A user can change commercial terms on a contract they are also activating. |
A segregation of duties testing workflow
The workflow moves from a written conflict policy to static detection and then to runtime proof.
Write the conflict ruleset
With process owners and internal control teams, define each sensitive process and the capability pairs that must not coexist, expressed as Salesforce permissions, objects, fields and approval steps.
Map capabilities to metadata
Translate each capability into the object permissions, field permissions, system permissions and approval process configuration that grant it.
Resolve effective access per user
Combine profile, directly assigned permission sets and permission set groups net of muting, so detection works on what each user actually holds.
Flag conflicting personas
Compare effective access against the ruleset and list every user or persona that satisfies both sides of a conflict, with the metadata that grants each side.
Prove it at runtime
Log in as a representative conflicting persona and attempt the full sequence, such as submitting and approving the same discount, to confirm whether a control stops it.
Record mitigations
For accepted conflicts, document the compensating control and add a scenario that proves it works, such as an approval step that rejects self-approval.
Where conflicts hide
Static reviews miss these paths because the conflicting capability is not granted by the permission reviewers are looking at.
Overlapping permission set groups
Muting in one group does not remove a permission granted by another group or a direct assignment, so the net result only appears when groups are combined.
Approval process design
Approver assignment by queue, manager field or related user can route a record back to its submitter unless the process explicitly prevents it.
System-context automation
A screen Flow or invocable action running without sharing can perform an update the user's own permissions would not allow.
Delegated and full administration
Users who can manage users or assign permission sets can create conflicts for themselves at any time, so admin access is its own conflict category.
Runtime scenarios worth automating
Each scenario tries to complete a separated process as a single persona and expects a control to stop it.
- A sales rep creates a quote with a discount above the approval threshold, submits it, and attempts to approve it from their own approval queue.
- A user who can edit commission records attempts to change the commission on an opportunity they own and have just closed.
- A service agent raises a refund case and attempts to move it to the approved status without a second user acting.
- A finance user updates an account's remittance details and then attempts to generate a payment request for the same account in one session.
- A delegated administrator attempts to assign themselves a permission set group outside the groups they are allowed to manage.
- A persona holding two overlapping permission set groups attempts an action that one group mutes, proving whether the other group grants it back.
Keeping segregation of duties controls from eroding
Conflicts accumulate over time. People change roles and keep old permission set groups, temporary access granted for a quarter-end close is never removed, and new permission sets are added to existing groups for unrelated reasons. A clean result at go-live says little about the org a year later.
That is why conflict detection and the runtime scenarios above belong in security regression testing, re-run after permission changes and on a regular schedule. Static comparison through permission set comparison shows which metadata changed; runtime scenarios show whether that change created a conflict a user can actually exploit. Integration identities deserve the same treatment, since a single API user often holds both create and approve rights for convenience — see integration user testing.
Where Salesforce processes feed ERP transactions, a conflict can span systems: a user who can edit customer terms in Salesforce and post credits in Oracle or SAP. SyntraFlow's Oracle-native background makes that cross-system view a natural extension, explored in cross-application testing.
What SyntraFlow is designed to do
These capabilities are available for demonstration and proof-of-concept validation against your conflict ruleset.
Effective access resolution
Access can be evaluated as the combined result of profile, permission sets and permission set groups, including muting.
Rule-based conflict detection
A customer-defined conflict ruleset can be applied to personas to list conflicting capability pairs and the metadata behind them.
Runtime conflict attempts
Scenarios can attempt a full separated process as one persona, so a control is proven by behavior rather than assumed.
Evidence for control reviews
Detected conflicts, mitigations and runtime outcomes can be retained as evidence to support internal control reviews.
Related pages
Salesforce security testing
The parent guide to validating every Salesforce access layer.
Permission set testing
Validates the sets and groups whose combinations create conflicts.
Integration user testing
Checks API identities that often hold conflicting rights.
Approval process testing
Covers the approval routing that many SoD controls rely on.
Permission set comparison
Shows which permission changes may have introduced a conflict.
Security regression testing
Re-runs conflict checks after every access change.
Segregation of Duties testing FAQs
What is Salesforce segregation of duties testing?
It is the process of finding users or personas whose combined Salesforce access lets one person complete a sensitive process alone, and proving whether controls stop them. It combines static conflict detection across profiles, permission sets and permission set groups with runtime scenarios that attempt the conflicting actions.
What is an SoD conflict in Salesforce?
It is a pair of capabilities that should be held by different people, such as creating a discount and approving it, or editing billing details and initiating payment. In Salesforce these capabilities come from object, field and system permissions, and from how approval processes and automation are configured.
Does muting in a permission set group prevent conflicts?
Only within that group. A muting permission set removes permissions from the group it belongs to, but a user can still receive the same permission from another group, a directly assigned permission set or their profile. That is why conflicts must be evaluated on each user's combined access.
Why test SoD at runtime if detection finds the conflict?
Detection shows that a user holds both capabilities. Runtime testing shows whether they can actually complete the process, because an approval process rule, validation rule or Flow may block it, or a system-context automation may enable it. Both results matter for deciding on remediation.
Who defines the conflict rules?
Process owners and internal control or audit teams define which duties must be separated. Salesforce and QA teams translate those rules into metadata terms and test scenarios. SyntraFlow is designed to apply a customer-defined ruleset rather than supply a universal one.
Does SyntraFlow certify SoD compliance?
No. SyntraFlow is designed to detect conflicts and evidence how controls behave, which can support internal reviews. Whether controls satisfy any regulatory or audit requirement is for your compliance function to determine, and capabilities are available for demonstration and proof-of-concept validation.
Find the users who can finish a sensitive process alone
See how conflict detection and runtime scenarios can prove your separation of duties holds.