Accelerating Salesforce with SOQL Query Merging

Recently, I had to block a deployment.

After months of effort spent on reducing CPU time and limiting the number of SOQL queries to stay within Salesforce governor limits, one of my developers submitted a feature for review. Unfortunately, it introduced yet another synchronous query into an already heavy transaction.

At first, my instinct was to move the logic into a Queueable job to offload the processing and avoid adding more pressure to the transaction. However, instead of jumping straight into a solution, I decided to step back and analyze the full transaction flow.

That decision changed everything.

Transaction Awareness Over Quick Fixes

While reviewing the transaction, I discovered that another part of the process was already querying the same Account records.

At that point, it became clear:instead of adding more logic or moving it elsewhere, the better solution was to merge the queries and reuse the data already available within the transaction.

This is something that is often overlooked. Developers tend to think in terms of isolated features, but Salesforce executes everything within a shared transaction context — triggers, flows, and automation all contribute to the same limits.

Optimizing within that shared context is where real performance gains happen.

A Note on AI-Generated Code

AI can be a useful tool, but it often lacks awareness of the broader transaction context.

It may generate code that works in isolation, but when placed into a real system, it can introduce inefficiencies such as redundant queries or duplicated logic. Without careful review, this can quickly lead to governor limit issues and degraded performance.

This is why architectural thinking and system awareness remain critical skills.

Transaction Journey Analysis

Before adding any new query or logic, it is essential to understand the full transaction journey.

You should always ask:

• Is similar data already being queried somewhere in this transaction?

• Is there logic running in triggers (e.g. before insert, before update) that already retrieves this data?

• Are there record-triggered flows executing in the same context that might overlap with this logic?

For example, if you are planning to query Account data from an Opportunity trigger, you need to verify whether:

• another trigger handler already queries Account

• a flow triggered on the same record is doing something similar

• existing logic can be reused instead of duplicated

Sometimes the right solution is not adding code — but refactoring and consolidating existing logic.

How to Merge SOQL Queries in Practice

There is no single recipe for merging SOQL queries, but based on experience, a structured approach helps.

1. Separate responsibilities

Before merging anything, split your logic into:

• logic executed before the query

• logic executed after the query

This makes dependencies clear and easier to refactor.

2. Isolate your new logic

Write your new functionality separately, even if it includes its own query initially.Then break it down into small, single-purpose methods.

3. Identify overlap

Find existing queries that retrieve the same object or similar data.

4. Merge the data source

Adjust the existing query so it satisfies both use cases:

• extend selected fields if needed

• adjust filters carefully

• ensure it still supports existing logic

5. Reconnect logic

Move:

• your pre-query logic before the shared query

• your post-query logic after it

6. Filter appropriately

Once you have a shared dataset, make sure each part of the logic operates only on the records it actually needs.

7. Validate everything

Test both:

• original functionality

• new functionality

Merging queries can introduce subtle side effects, so regression testing is critical.