Salesforce Pull Request Testing
Salesforce pull request testing validates a proposed metadata change while it is still a pull request, so reviewers see deployability, Apex test results, access impact and functional behavior next to the diff before approving a merge. Stopping a regression at the pull request keeps the shared branch deployable, gives the author feedback while the change is fresh, and turns code review for Flows and permission sets into an informed decision.
SyntraFlow is designed to run focused functional checks for a pull request and report results back to it; this is available for demonstration and proof-of-concept validation.
Why pull requests are hard to review on Salesforce
On most codebases a reviewer can read a diff and reason about its effect. Salesforce metadata makes that difficult. A record-triggered Flow is stored as a long XML file where moving one element on the canvas rewrites coordinates throughout, a profile file can change hundreds of lines when a single field permission is touched, and a small change to a custom object's field can alter layouts, list views, reports and integrations that do not appear in the pull request at all. Reviewers end up approving changes they cannot fully evaluate by reading.
Pull request testing supplies the evidence a diff cannot. Automated checks answer whether the change deploys to a realistic org, whether Apex tests still pass, whether access widened or narrowed for key personas, and whether the business journeys the change touches still complete. The results sit on the pull request as status checks and a summary comment, so the approval decision includes them.
This page is about the pull request as the unit of validation, whichever Git host or CI service runs it, whether GitHub, GitLab merge requests, Bitbucket or Azure Repos. Workflow mechanics for one specific service are on GitHub Actions and Azure DevOps; how results become enforceable rules is on quality gates.
Checks worth running on every Salesforce pull request
A useful pull request suite is layered, from cheap static checks to focused functional tests.
Source and metadata validity
Confirm the source-format metadata parses, the package directory is consistent, and no unintended files such as org-specific settings slipped into the branch.
Static analysis
Run a code analyzer over Apex and Lightning Web Components for security and quality rules, and lint Flow metadata for patterns such as hard-coded IDs.
Check-only deployment
Validate the change against an org that resembles the target, so missing dependencies and API version conflicts surface before merge.
Relevant Apex tests
Run the tests that cover changed classes and triggers with a specified test level and report coverage for those classes.
Access comparison
Summarize permission changes in human terms, such as which objects or fields a permission set now grants, using permission set comparison.
Focused functional tests
Exercise the business journeys mapped to the changed components, as the personas who use them, in the pull request environment.
Environment strategies for pull request validation
Where the checks run determines how reliable and how fast they are. Each option has trade-offs for Salesforce teams.
| Environment | Strengths | Watch out for |
|---|---|---|
| Scratch org per pull request | Clean, isolated, disposable; suits source-tracked and package-based projects | Daily and active allocation limits, empty data, features that need extra definition settings |
| Shared validation sandbox | Production-like configuration, reuses existing data | Concurrent pull requests overwrite each other unless runs are queued |
| Pool of developer sandboxes | Parallel runs without scratch org limits | Drift between pool members and refresh overhead |
| Check-only deploy against production | Most accurate deployability signal | No functional tests possible; long RunLocalTests times |
| Partial copy sandbox with seeded data | Realistic records for functional tests | Refresh interval limits and data masking obligations |
| Hybrid: scratch org plus nightly sandbox | Fast pull request feedback, deeper coverage daily | Some regressions surface a day later rather than at merge |
A pull request validation flow
The sequence below keeps feedback fast while still giving reviewers the evidence they need.
Detect the changed components
Diff the pull request branch against its target and list changed metadata by type, which a metadata diff can present in readable form.
Prepare the environment
Create a scratch org or claim a validation sandbox, deploy the base branch state if needed, then apply the pull request changes.
Seed only the data the tests need
Load reference records such as price books, queues and test accounts so functional checks do not depend on leftover data.
Run fast checks first
Static analysis and the check-only deployment fail quickly and cheaply, so run them before functional tests to save time.
Run impact-selected functional tests
Select tests from changed components using dependency analysis and execute them as the relevant personas.
Report back on the pull request
Post status checks and a comment summarizing what ran, what failed, the affected journeys and a link to evidence.
Release the environment
Delete the scratch org or reset the sandbox so the next pull request starts from a known baseline.
Making results useful to reviewers
A failing check that only says the job failed wastes the reviewer's time. The pull request summary should name the business journey that failed, the persona, the step and the assertion, and relate it back to the component in the diff. For example: the Opportunity close-won journey failed for the Sales User persona because a validation rule added in this pull request requires Next Step on closed opportunities. That tells the author what to fix and tells the reviewer what the change actually does.
Results must also stay current. If the target branch moves or the author pushes a new commit, earlier results no longer describe what will be merged, so checks should rerun on each update and ideally against the latest target branch state. Where the Git host supports a merge queue, running the heavier functional checks on the queued merge result catches conflicts between two pull requests that each passed on their own.
Regressions pull request testing is designed to stop
These are specific, recurring Salesforce problems that are cheaper to catch before merge than after.
- A permission set added for a new feature also grants Modify All on an object, which an access check flags before it reaches the main branch.
- A Flow change removes a decision outcome that another team's subflow depends on, breaking their journey in a different app.
- Two pull requests each edit the same profile, and the second silently reverts a field permission from the first.
- A new custom field is marked required on the layout but not granted field-level security for the integration user, see integration user testing.
- An Apex class change passes its own tests but lowers coverage elsewhere, pushing the org toward the production threshold.
- A Lightning Web Component references a field removed in the same branch, which only a deployment check would reveal.
- A hard-coded record type ID works in the developer's sandbox and fails in every other org.
Keeping pull request checks fast enough to trust
If checks take too long, people merge before they finish. These practices keep pull request testing within reach of a normal review cycle.
Test selection over full runs
Run only what the changed components can affect, and leave full regression to merge or nightly runs described on continuous testing.
Parallel environments
Give concurrent pull requests their own scratch org or pooled sandbox rather than queueing all of them on one org.
Quarantine flaky tests
Move tests that fail intermittently out of the blocking set until fixed, so authors learn to trust red results.
Fail fast ordering
Put static analysis and the check-only deploy ahead of functional tests so obvious problems return within minutes.
Where SyntraFlow fits in pull request testing
SyntraFlow is designed to supply the functional layer of pull request validation. A CI job for the pull request can start a SyntraFlow run with the environment and the changed component list, SyntraFlow can recommend relevant regression packs, and the result is returned in a form the job can turn into a status check and a reviewer-friendly summary. Static analysis, the check-only deployment and Apex tests remain with the team's existing tooling.
No native integration with a specific Git host is claimed; the pattern works through the generic job-and-result interface that CI services share. It is available for demonstration and proof-of-concept validation, typically starting with one repository and a small set of high-value journeys such as lead conversion or case routing.
Related pages
Salesforce DevOps Testing
The hub for validation layers across the Salesforce delivery pipeline.
GitHub Actions
Workflow mechanics for running pull request checks on GitHub.
Quality Gates
Turn pull request results into merge rules with thresholds and overrides.
Continuous Testing
Validation that runs across the whole pipeline, beyond the pull request.
Dependency Analysis
Find what a changed component affects so the right tests run on the pull request.
Permission Set Comparison
Show reviewers exactly how access changes in a pull request.
Pull Request Testing testing FAQs
What is Salesforce pull request testing?
It is automated validation of a Salesforce metadata change while it is still an open pull request. Typical checks include static analysis, a check-only deployment, relevant Apex tests, access comparison and focused functional tests, with results posted to the pull request before anyone approves the merge.
Should pull request tests use scratch orgs or sandboxes?
Scratch orgs give clean, isolated runs and suit source-tracked or package-based projects, but they start empty and are subject to allocation limits. Sandboxes are more production-like but need queuing or pooling to avoid collisions. Many teams use scratch orgs for pull requests and a sandbox for merge or nightly regression.
How do I test a Flow change in a pull request?
Deploy the Flow to the pull request environment, seed the records it needs, and run a functional test that triggers it as the affected persona and asserts the resulting field values, tasks or routing. Reading the Flow XML diff alone is rarely enough to judge its behavior.
Can pull request testing run on GitLab, Bitbucket or Azure Repos?
Yes. The practice is independent of the Git host. Each service offers a way to run jobs on merge or pull requests and report status, and the same validation layers apply.
What if functional tests take too long for every pull request?
Select tests based on changed components, run environments in parallel, and move full regression to merge or nightly runs. Quarantining flaky tests also matters, because authors stop waiting for checks they do not trust.
Does SyntraFlow review the code in a pull request?
No. SyntraFlow is designed to run functional validation for the change and report results back. Code review, static analysis and Apex tests stay with reviewers and the team's existing tools.
Stop Salesforce regressions at the merge
See how SyntraFlow is designed to put functional test results on your pull requests before reviewers approve.