The most expensive Salesforce bug is not always the one that breaks for everyone. It is often the one that fails for one user, on one record, after one apparently unrelated change—and then works perfectly when an administrator tries it.
These “needle in the haystack” issues consume time because Salesforce behaviour is assembled from many layers. A single save can involve field permissions, validation rules, record-triggered flows, Apex triggers, managed-package code, duplicate rules and an integration. Looking at those layers one at a time, in no particular order, creates activity rather than progress.
A better approach is to shrink the search space with evidence.
Start with a transaction, not a theory
Before opening Setup, capture the smallest useful incident record:
- the affected user's name and profile or permission sets;
- the exact date and time, including time zone;
- the record ID and object;
- the action the user took;
- the expected and actual result;
- the exact error text or error ID;
- whether retrying changed the outcome;
- whether the same action works for another user or record.
“Opportunity save is broken” gives you an entire org to investigate. “User A received this error at 10:42 AEST while changing Opportunity 006… from Proposal to Closed Won” gives you a transaction you can trace.
Do not tidy away the strange detail. Intermittent bugs are often explained by the thing that seems irrelevant: a different record type, a blank lookup, a community user, a batch size of 200, or a value copied from an integration.
Reproduce by changing one dimension at a time
Build a small comparison matrix instead of repeatedly clicking and hoping.
| Dimension | Working case | Failing case |
|---|---|---|
| User | Administrator | Sales user |
| Record | New test record | Existing migrated record |
| Channel | Salesforce UI | Integration/API |
| Volume | One record | Bulk update |
| Environment | Sandbox | Production |
Change one dimension per test. If the same record succeeds for an administrator and fails for the user, permissions or user-context automation move to the top of the list. If one record fails for everybody, inspect its data and relationships. If single-record saves work but an import fails, look for bulk-safety and limit consumption.
Reproduce as the affected user where possible. An administrator's broad access can hide the exact field-level or record-level restriction that triggered the problem.
Map everything that can fire
For a record-save problem, inventory the automation before reading any one component deeply:
- validation rules;
- before-save and after-save flows;
- Apex triggers and their handler classes;
- workflow rules or Process Builder processes still present in an older org;
- duplicate rules;
- roll-up behaviour and cross-object updates;
- platform events, scheduled work and queueable jobs;
- managed-package automation;
- outbound integrations and callbacks.
The goal is a map of candidates and their order, not an immediate code review. A field referenced in a validation rule may have been changed by an earlier flow. A trigger may enqueue work whose failure appears minutes later. The visible error can be several steps away from the cause.
The orgadmin.ai AI Org Chat can summarise the automation attached to an object and trace references across flows, validation rules and Apex. This is useful for building the map quickly; it does not remove the need to verify the transaction itself.
Use the right evidence for the failing layer
Flow failures
Start with the flow error email and failed interview, when Salesforce retained one. The message can identify the failing element, the values assigned immediately beforehand and the flow version that ran.
Not every failed interview is retained. Salesforce documents conditions and limits around saved failures, including cases handled by a fault connector. That means “there is no failed interview” is not proof that no flow failed.
Look for missing fault paths, null values, permission differences, unexpected collections and subflows that pass the wrong variable. Test the active version as the affected user.
Apex and transaction failures
Use a trace flag for the user and a debug level that captures the relevant categories without generating unnecessary noise. Salesforce debug logs can include database activity, workflow, validation, Apex execution, callouts and profiling information.
Keep the capture window narrow. Salesforce warns that high-volume trace flags can create large logs and affect requests, and oversized logs can lose lines. Reproduce the smallest possible transaction, then turn the trace off.
In the log, work from anchors rather than reading from line one:
- exception type and message;
FATAL_ERRORor unhandled fault;- the final DML operation before failure;
- SOQL and DML limit totals;
- the first entry into custom code;
- validation-rule evaluations;
- callout status and response;
- asynchronous job IDs that continue elsewhere.
The Debug Logs feature can correlate up to five related logs and surface exceptions, slow queries, DML and governor-limit consumption. That is especially helpful when a user's retries created several transactions or one action crossed synchronous and asynchronous work.
Permission-specific failures
Compare the affected user's effective access, not just their profile. Permission sets, permission-set groups, sharing, role hierarchy, teams and ownership can all change the result.
Check object access, field-level access, Apex class access and record access separately. “The user can open the Account” does not mean they can update the field that a downstream flow writes.
Recent configuration changes
Use Setup Audit Trail and deployment history to ask what changed immediately before the symptom appeared. New permission assignments, activated flows, field changes and package upgrades can all explain a bug without appearing in the failing component's source.
Time correlation is evidence, not proof. Confirm the suspected change against the failing transaction before rolling anything back.
Search for the contradiction
Hard bugs are often two individually reasonable rules colliding:
- a validation rule requires a field that an integration cannot see;
- a flow assumes a lookup is populated, while migration data permits it to be blank;
- an Apex trigger is bulk-safe until another automation adds a query per record;
- a duplicate rule blocks an upsert key the migration team thought was unique;
- a process runs in a different user context from the one used during testing.
Write down the assumptions made by each layer. The contradiction becomes easier to see when “this field is always populated” sits beside a real failing record where it is not.
Prove the fix and check the blast radius
A bug is not fixed because the original click worked once.
Retest:
- the exact user, record and action that failed;
- a normal working case;
- a bulk case if the automation can run in bulk;
- a user with different access;
- any asynchronous or integration outcome;
- the relevant tests and deployment validation.
Then add monitoring or fault handling so the next failure is observable. A useful fix makes the system easier to diagnose as well as correcting the immediate condition.
Turn the investigation into org knowledge
Record the root cause, the evidence that confirmed it, the change made and the test that proves it. Avoid a note that only says “fixed Flow.” The next person needs the relationship between symptom and cause.
orgadmin.ai can retain durable learnings against an org connection, such as the meaning of a business status or the automation responsible for a transition. Used carefully, that turns a one-off investigation into context for the next question rather than another piece of knowledge trapped in an inbox.
Find the next needle faster
Connect a sandbox to orgadmin.ai and use the assistant, automation summaries, Flow Health and log analysis to assemble the evidence around a difficult issue. The aim is not to let AI guess at the answer; it is to give the investigation a complete map and a shorter feedback loop.