Salesforce Testing
Salesforce CRM and Service Cloud are ubiquitous in NZ enterprise. Learn to test Flows, Apex triggers, permission sets, and integrations — plus how to use Provar and Copado Robot for automation.
1 The Hook
An Auckland insurance company deployed a new Salesforce Flow for claims processing. The Flow worked correctly — it created the claim record, set the right status, and fired the right notifications. UAT was signed off on a Thursday. Go-live was Monday.
By Tuesday morning the helpdesk was flooded with calls. Claims handlers in the Wellington office could not view the new custom object the Flow created. Their Auckland colleagues could see it fine. The difference: Wellington claims handlers used a slightly different profile, and the permission set that granted access to the new custom object had only been assigned to the Auckland user group. Admins had tested with full System Administrator access and had never encountered the restriction.
Cost: a two-day rollback, a re-test cycle, and a delay to a regulatory reporting deadline. The defect was not in the Flow logic. It was in the access model. The permission set was the invisible bug.
2 The Rule
Always run Salesforce UAT as the actual end-user profile, not as an admin or developer. Permission sets are invisible bugs until a real user hits them. If your UAT was run by admins, you did not run UAT — you ran a demo. Test as every type of user, in every affected office, with their actual profiles and permission sets.
3 The Analogy
Salesforce is like a theme park with dozens of rides and strict access gates.
The rides are the features: Sales Cloud, Service Cloud, Marketing Cloud, Experience Cloud, custom objects, reports, dashboards. Each ride might work perfectly. But the access gates — profiles, permission sets, sharing rules, field-level security — determine who actually gets on. A System Administrator has a VIP pass that bypasses every gate. Testing as an admin means you never test the gates.
Test as every type of guest, not just the VIP. In NZ insurance, “every type of guest” means the Auckland claims handler, the Wellington claims handler, the team leader, the read-only auditor, and the external broker. Each one has a different access gate configuration, and each one can be broken independently.
4 Watch Me Do It
Here is a complete test case for a Salesforce Opportunity-to-Quote Flow, tested as the correct user profile:
Profile under test: Sales Representative (NOT System Administrator)
Steps:
1. Log in as SalesRep_TestUser (profile: Sales Representative)
2. Navigate to Opportunities → Create New
3. Enter: Account = Resync NZ Ltd, Close Date = 30 days future,
Stage = Prospecting, Amount = $45,000 NZD
4. Save → verify Opportunity created and visible to this profile
5. Click “Create Quote” button → verify Flow triggers (spinner, then redirect)
6. Verify Quote record auto-created with line items from product catalogue
7. Verify approval request email sent to Manager_TestUser
8. Log out; log in as Manager_TestUser (profile: Sales Manager)
9. Navigate to approval request → approve the Quote
10. Verify Opportunity Stage changes to “Proposal/Price Quote” automatically
11. Verify PDF quote generated and attached to the Opportunity record
12. Log back in as SalesRep_TestUser → verify they can see the approved Quote
Expected: Flow runs; permissions correct for both profiles; approval routing correct;
PDF generated; stage auto-updates; both profiles can see the result.
Failure modes: Flow does not trigger (profile missing button access); Quote not
visible to sales rep (sharing rule missing); PDF not attached; stage does not update.
5 Decision Tool
Salesforce has a maturing ecosystem of test automation tools. Choosing the right one depends on your programme scale and budget:
| Tool | Best for | Trade-offs |
|---|---|---|
| Manual testing | All Salesforce UAT; permission set and sharing rule verification; Flow exploration in new builds | Not scalable for regression across Salesforce’s 3 annual releases |
| Provar | Salesforce-native UI automation; understands Lightning components, dynamic IDs, and Salesforce navigation natively; widely used on NZ Salesforce programmes | Licenced tool; requires Provar skill investment; best for large, long-running programmes |
| Copado Robot | Teams using the Copado DevOps platform for Salesforce CI/CD; integrates with Copado pipelines directly | Tightly coupled to the Copado ecosystem; not portable outside it |
| Selenium / Playwright | Lightweight, licence-free automation for stable Salesforce flows | Salesforce Lightning’s dynamic IDs and shadow DOM make selectors fragile; high maintenance cost versus Provar |
| Apex unit tests | Developer-written tests for Apex triggers and classes; required by Salesforce (75% code coverage) for any deployment | Tests Apex logic only — does not test UI, Flows, or permission sets |
6 Common Mistakes
🚫 Running all tests as System Administrator
Why it happens: Admins have all the access they need and do not encounter any permission issues, so testing feels clean and fast.
The fix: System Administrator bypasses every permission check in Salesforce. Testing as admin proves the features work, not that real users can access them. Create dedicated test users for every profile in scope (e.g. SalesRep_Test, ServiceAgent_Test, Manager_Test, ReadOnly_Test) and run all functional and UAT scripts as those users. Permission errors are the most common Salesforce go-live defect and the most avoidable.
🚫 Not testing in a Full Copy sandbox before production
Why it happens: Full Copy sandboxes take hours to create and are expensive to run; teams use Developer or Developer Pro sandboxes throughout testing.
The fix: Developer sandboxes have no production data, a different data volume, and may have different metadata. A Full Copy sandbox is the only environment that replicates production configuration, profiles, permission sets, sharing rules, and data volumes accurately. At minimum, run a final UAT and regression cycle in a Full Copy or Partial Copy sandbox before go-live. Defects that only surface with production data volumes or the full metadata set are common and serious.
🚫 Missing async Apex triggers that fire after record save
Why it happens: Apex triggers appear to complete when the save confirmation appears, but some Apex runs asynchronously in a future context or as a queued job.
The fix: After any record save that involves Apex triggers, wait a few seconds and refresh the record before asserting the expected outcome. Better: ask the developer which Apex in scope is synchronous versus asynchronous (future, queueable, or batch), and design your test steps accordingly. An asynchronous trigger that fails appears as no action taken — the record saves but nothing happens. Check the Apex Jobs log in Setup to see if jobs errored.
7 Now You Try
Paste or edit the prompt below, then click Run to get a real AI response.
8 Self-Check
Click each question to reveal the answer.
Q1: Why is testing as System Administrator in Salesforce a critical gap, and what is the fix?
System Administrator has bypass-all permissions in Salesforce, meaning every object, field, and record is visible and editable regardless of profiles, permission sets, sharing rules, or field-level security. Testing as admin proves the features exist, not that real users can access them. The fix is to create test users with the exact profiles and permission sets that production users will have, and run all functional and UAT testing as those users. The Auckland insurance example in the Hook shows exactly what happens when this step is skipped: a feature that works for admins is invisible to the users it was built for.
Q2: How do you test a Salesforce Flow end-to-end?
Testing a Salesforce Flow end-to-end requires four things: (1) trigger it correctly — understand whether the Flow is screen-triggered (user action), record-triggered (on save), or scheduled, and trigger it in the way production users will; (2) test as the correct user profile, not as admin; (3) verify every expected outcome — records created or updated, emails sent, approval requests raised, field values set; (4) verify the failure path — what happens if a Flow element encounters an error (Salesforce can route to a fault path or show a generic error; both should be tested). Also check that the Flow’s debug log or interview in the Flow Builder shows the path taken during your test run — this confirms which elements executed.
Q3: What is the difference between a profile and a permission set in Salesforce, and why do both matter for testing?
A profile is the baseline access model assigned to every user — it defines what objects they can see, what they can do with records (read/create/edit/delete), and what applications they can access. Every user has exactly one profile. A permission set grants additional permissions on top of the profile — it is additive, not restrictive. A user can have multiple permission sets. Both matter for testing because a user’s effective access is the combination of their profile plus all their permission sets. A common defect is deploying a new feature and forgetting to assign the permission set to some user groups (as in the Auckland insurance example) — the profile has no access by default, and the permission set assignment was missed. Testing must verify access for every profile/permission-set combination in scope.
9 Interview Prep
Real questions asked in NZ QA interviews for Salesforce roles. Read the model answers, then practise your own version.
“How do you test a Salesforce Flow end-to-end?”
I approach Flow testing in four steps. First, understand the trigger: is it a screen flow (user-initiated), a record-triggered flow (fires on save), or a scheduled flow? I trigger it the same way production users will — via the correct button, the correct record save, or by running the schedule manually. Second, I test as the actual end-user profile, not as System Administrator. Third, I verify every expected outcome: the records created or updated, the emails sent, the approval requests raised, and the field values set. I check the Flow debug log in the Flow Builder to confirm which path executed. Fourth, I test the error path — what happens when a Flow element fails? Does it route to a fault path with a useful message, or does it show a generic error? On any NZ Salesforce programme I have worked on, the fault path is one of the most frequently broken parts of a Flow because it is rarely tested.
“What’s the difference between a profile and a permission set, and why do both matter for testing?”
A profile is a user’s baseline access — every user has exactly one, and it defines their default object-level, field-level, and application access. A permission set grants additional permissions on top of the profile; a user can have multiple permission sets. The effective access is the combination of both. They both matter for testing because the most common Salesforce access defect is assigning a permission set to some user groups but not others — the feature works for the users who got the permission set, and is completely invisible to those who did not. The only way to catch this is to test as every profile in scope, with the specific permission sets that user group will have in production. I always build a user access matrix before UAT: every profile, every permission set, what they should see, and who will test that combination.
You’ve completed the ERP Programme Testing track.
You can now approach ERP testing from first principles — configuration-first methodology, platform-specific patterns for Oracle Fusion, D365, and Salesforce, and the permission and access testing that catches the defects that every admin-only UAT misses. These are skills that are genuinely scarce in the NZ market.