Salesforce Flow’s delete element throws a fault when the target collection is empty or a single record doesn’t exist, displaying the message “No records in Salesforce match your delete criteria”. This forces admins to add pre‑validation checks, such as confirming the collection isn’t empty, before proceeding. The author suggests adding an optional “Continue if no records are deleted” checkbox to streamline flows. The takeaway is to verify record existence before invoking a delete step.
Salesforce Flow has become the go‑to low‑code tool for automating data operations across the platform, yet its delete element still treats an empty target as an error. When a flow attempts to delete a collection that contains zero records—or a single record that no longer exists—the engine throws a fault with the message “No records in Salesforce match your delete criteria”. This behavior interrupts the execution path, forces the fault branch to run, and requires administrators to build extra logic solely to catch a situation that should be harmless. The result is longer build times and a higher chance of unintended side effects.
Practitioners have adopted several workarounds to sidestep the fault. The most common pattern adds a decision element that checks “Collection is empty = false” before the delete step, effectively gating the operation. For single‑record deletions, a Get Records element can confirm existence, then feed the ID into the delete. While functional, these safeguards add nodes, increase flow complexity, and make maintenance harder, especially in large orgs with dozens of automated processes. Moreover, the extra steps consume governor limits, which can be critical in high‑volume environments.
Introducing an optional “Continue if no records are deleted” checkbox on the delete element would eliminate the need for defensive branching. Such a feature aligns with Salesforce’s broader push toward frictionless automation and would reduce both development overhead and runtime governor consumption. It also signals a maturing platform that listens to community feedback, encouraging wider adoption of Flow for data‑centric use cases. As low‑code platforms compete on ease of use, removing this edge case could set a new standard for error handling, benefiting admins, developers, and end‑users alike.
Comments
Want to join the conversation?