In large Salesforce orgs, it’s very easy to miss things during manual testing—especially after trigger or automation changes. One area that is often overlooked is Screen Flows.
At first glance, this might seem harmless. You update a trigger, run your tests, do bulk testing, everything looks fine, and the change goes to production. But then, during user execution at runtime, you start seeing errors like “Too many SOQL queries: 101 in a single transaction”, and the stack trace points… to a Flow.
How does this happen?
A Very Common Real-Life Scenario
Imagine this situation:
- You add new logic to an Account trigger
- The trigger performs an extra SOQL query
- You test it with trigger-focused tests (manual or automated):
- Single record ✅
- Bulk operations ✅
- Everything passes, so you deploy to production
Later, users start reporting errors when running a Screen Flow.
After investigation, you discover the root cause:
- The Screen Flow executes as a single transaction spanning multiple screen interactions
- Inside that transaction, multiple DML operations occur
- One of those operations updates an Account
- Your updated trigger runs
- Combined trigger + Flow logic pushes the transaction over the SOQL limit
Nothing was technically “wrong” with the trigger or the Flow in isolation—but together, they break governor limits.
Why Manual Testing Is Not Enough
A common reaction after finding the root cause is to say:
“From now on, whenever Account logic changes, testers must test this Screen Flow.”
While this sounds reasonable, it’s not a reliable solution.
- Testers change over time
- Knowledge gets lost
- Human error is inevitable
- The org grows, and dependencies multiply
Relying on people to remember every Flow-Trigger interaction is not scalable.
A Better Approach: Test It with Apex
A more robust and long-term solution is to cover this scenario with Apex tests.
The good news:
You don’t need complex UI testing or UI-dependent, screen-based Flow interviews that slow down your test suite.
The key idea is simple:
👉 Move the logic that runs between screens into a Subflow.
Why Subflows Make Testing Easier
When you extract the transactional logic into a Subflow:
- The Screen Flow stays focused on UI
- The Subflow contains the business logic and DML
- The Subflow can be invoked from Apex tests via Flow interviews
- You can simulate real trigger + Flow interactions
- You can catch SOQL/DML limit issues early
This approach gives you:
- Stable, fast Apex tests
- No dependency on UI automation
- Protection against “sneaky” limit issues caused by combined automation
Final Thoughts
Screen Flows are powerful, but they don’t run in isolation. In real orgs, they interact with triggers, Process Builder (still out there), other Flows, and integrations—all within the same transaction.
If you’re changing trigger logic in a mature org and Screen Flows touch the same objects, testing only the trigger is not enough.
By:
- Extracting transactional logic into Subflows
- Writing focused Apex tests that cover transactional and business logic, not the screen layer
…you can prevent governor limit issues, reduce production surprises, and make your automation architecture far more resilient.
Simple, elegant, and very Salesforce-native. 🚀
Leave a Reply