A private lending client asked a question that sounds simple until you actually have to prove the answer: a Salesforce record for an active loan was gone. It was not coming up in normal search. It was not in the Recycle Bin. The team had evidence that it had existed, but nobody could find the record itself.
That is the kind of Salesforce problem where it is easy to either underreact or overreact. Underreact, and you tell the client, “I do not see it,” which is not an investigation. Overreact, and every auto-number gap becomes a possible deleted loan. Neither helps.
The useful work was not finding the record. I did not recover it. The useful work was proving the shape of the problem: one independently evidenced missing record, not a visible pattern of random missing records across the population I checked.
The first question: did the record really exist?
The first trap in a missing-record investigation is treating a name, number, or memory as proof. It is not enough for someone to say, “I know this was there.” I needed independent evidence.
In this case, there were three useful signals:
- A Salesforce status-change email from August 1, 2025, for the specific record.
- A Salesforce-generated portfolio report, generated on April 3, 2026, that still included the record.
- A note on the prior related loan record linking forward to the refinance record.
The prior loan was marked paid off during the refinance, and its internal note contained a direct Salesforce link to the replacement transaction. Separately, the operations team could see the refinance in its servicing and accounting systems. The cross-system confirmation established the business event, not the Salesforce record by itself. The Salesforce link, email, and report established that. Keeping those roles separate is why the missing record was not inferred from a number gap or a staff recollection alone.
That changed the question. This was not just “a user cannot find a record.” This was “a record with independent Salesforce evidence appears to be missing from the current org.” That is a much narrower and more serious problem.
The second question: is it active, deleted, or gone?
Salesforce has an important distinction here. A normal delete should leave a record visible through deleted-record paths until it is permanently purged. In SOQL, ALL ROWS can return records that are still visible as deleted. The Recycle Bin is the user-facing version of that same practical idea.
So I checked the record through the paths that matter:
- direct lookup by Salesforce Id
- lookup by transaction name
- lookup by loan number
- lookup by borrower and property context
Loan_Transaction__cqueries withALL ROWSIsDeleted = truerows for the custom Loan Transaction objectDeleteEventrows for Loan Transaction
The result was uncomfortable but clear: the record was not active, and it was not visible as a soft-deleted record. The visible deleted-record set only showed an unrelated test record.
That does not prove who deleted it. It also does not prove how it was purged. But it does argue against the simple theory that a normal Flow deleted the record and left it sitting in the Recycle Bin.
The misleading clue: auto-number gaps
The missing record sat in an auto-number sequence. The surrounding records existed. The missing number was tempting evidence.
Tempting, but not enough.
Salesforce auto-number gaps can happen for reasons that are not business-record deletion: failed creates, rolled-back transactions, imports, tests, old deleted records, or records that were permanently purged. A gap tells me where to look. It does not tell me what happened.
That distinction mattered. I ran a broader check across Loan Transactions created since January 1, 2025. The current and deleted Salesforce data contained 711 Loan Transaction records in that window, spanning Transaction-03827 through Transaction-04553. There were 16 auto-number gap candidates.
Only one of those 16 gaps had independent evidence in the client-supplied Salesforce report.
That was the useful finding. Not “there are 16 missing loans.” There were 16 gaps. One had evidence that it was a real record that existed. The others were leads, not conclusions.
Checking whether this was a broader data-loss pattern
The client concern was valid: if one active loan record disappeared, could others have disappeared too?
I compared the Salesforce-generated portfolio report against the current Salesforce Loan Transaction table using ALL ROWS. That report had 158 Loan Transaction rows. Of those, 157 still existed in current Salesforce. The only row missing from current Salesforce, including deleted/all-rows results, was the one already under investigation.
I also checked the visible deleted Loan Transaction records and DeleteEvent. No other report row was sitting in the Recycle Bin. The only visible deleted Loan Transaction and the only visible Loan Transaction delete event were for the same unrelated test record.
That did not solve the original disappearance. But it changed the risk conversation. The evidence no longer supported “random loans are disappearing.” It supported “one independently evidenced record is missing, and I do not yet have the deletion mechanism.” Those are very different states.
Checking automation without blaming automation
Salesforce automation is often guilty enough that it gets blamed even when it did not do the thing. I checked it anyway.
The local Salesforce metadata did not show a Flow Delete Records element, Apex delete call, emptyRecycleBin, or obvious hard-delete pattern for Loan Transactions. That does not rule out every external process, API tool, admin action, data-loader operation, or retention edge case. It does make “a current Flow randomly deleted this” a weak theory.
This is where the wording matters. I could not say, “Automation did not delete it.” I could say, “I am not seeing evidence that current Salesforce automation deleted it, and a normal delete should still be visible through deleted-record paths unless it was permanently purged.” That is less satisfying. It is also more honest.
Why the system model mattered
I was not carrying every detail of the client’s lending business in my head. I did not need to. What made the investigation practical was having a maintained model of the system: the core Salesforce objects, the important control fields, the automation areas, the known risk zones, the source exports, and the things still marked unknown.
That model gave the work a map. It told me that this custom Loan Transaction object was central, that status and related process records mattered, that automation density was high, and that deleted-record checks alone would not answer the scope question. From there, the live Salesforce queries and report reconciliation had somewhere to go.
This is the part of systems work that is easy to miss from the outside. The force multiplier is not just speed. It is context. A tool can only reason from the context it can see; a maintained system model gives the investigation a wider vantage point than any single Salesforce screen, report, or memory of the business.
The AI lesson here is not that a model can pronounce a record deleted. It cannot. The useful role was more disciplined: help turn a vague concern into testable questions, keep the evidence types separate, surface the right comparisons, and preserve the difference between what was confirmed, what was plausible, and what remained unknown. The human part was still essential: knowing which business question mattered, judging the evidence, and deciding what conclusion was responsible to give the client.
The first evidence-backed answer went back to the client about 52 minutes after the original request. That is not a claim that the entire population-level reconciliation took 52 minutes; the broader study followed during the same day. It is a useful measure of what changed. Without the system map and assisted analysis, this would likely have meant a Salesforce-console specialist, a pile of exports and spreadsheet work, or a consultant already deeply fluent in the lender’s product. Instead, my systems judgment and the client’s business context could direct the work while the model helped make the evidence searchable, comparable, and testable.
What I would check first next time
- Find independent evidence that the record existed before treating it as a missing-record incident.
- Query active records and deleted/all-rows records separately, then compare the results.
- Check
DeleteEvent, but do not assume it is a complete historical audit trail. - Review automation for delete or hard-delete paths, but do not blame automation without evidence.
- Use auto-number gaps as leads, not proof.
- Run a population-level reconciliation so the client can distinguish an isolated issue from a systemic one.
The conclusion
The missing record was not recovered. I also did not identify the exact actor or mechanism that removed it. The available evidence pointed more toward a permanent removal path than an ordinary soft delete, but the root cause remained unknown.
What the investigation did prove was scope. Across the report population, one record was missing and 157 still existed. Across the post-January-2025 auto-number window, there were 16 gaps, but only one gap had independent evidence that it represented a real Salesforce record.
That is a useful outcome. Sometimes the job is not to produce a perfect answer. Sometimes the job is to stop the wrong panic, preserve the real concern, and give the client a clean map of what is known, what is inferred, and what is still unknown.
Debriefs are drafted from live working-session context by the engineering harness that did the work, then reviewed, verified, and published by me.
