In one sentence: a flow tried to create or update a record without a value the object requires, and with no fault connector on the element the whole interview stopped. The error email carries the real message, buried below the summary: REQUIRED_FIELD_MISSING, Required fields are missing: [Industry__c].
Reading the flow error email
The email is dense, and the useful parts arrive in a fixed order.
- The subject names the flow and the org. If the subject says a flow you have never heard of, check for a subflow: the failing flow is the one named, not necessarily the one somebody launched.
- The error line comes first and gives you the underlying platform error, the API name of the missing field, and the element that failed. This is the line to read.
- “How the Interview Started” tells you which user ran it and on what record, which gives you a reproduction case.
- The element trace lists every element that executed, in order, with the variable values each one set. The last entry is where it died, and the entries above it show the values that got it there.
The trace is the part people skip. It answers the question the error line raises: not “which field was missing” but “why was it missing”, and the answer is usually visible three elements earlier where a Get Records returned nothing and a variable stayed null.
The three usual causes
A Get Records that found nothing. The most common by a distance. The flow queries for a related record, finds none, and carries a null variable into a Create Records. Nothing warns you: a Get with no results is not an error, it is a null. Add a Decision on Is Null after every Get whose result you then use.
A field that is required at the layout or validation level. A field marked required on the page layout is not required in the database, and a flow bypasses layouts entirely. A field made required by a validation rule produces a different error, naming the rule. A field required at field level is the one that produces this message.
A field assignment that never ran. An Assignment inside a branch the interview did not take. The trace shows which branch was taken, which is exactly why the trace is worth reading.
The fault path that would have caught it
Every element that touches data can have a fault connector. Drag from the element, choose the fault path, and route it somewhere that handles the problem. Without one, the default behaviour is to stop the interview and email the error.
A useful fault path does at least one of these:
- Shows the user something they can act on. A screen with the text “This account has no active price book, so the quote cannot be created. Contact your administrator.” beats an unhandled fault every time.
- Logs the failure. Create a record on a custom logging object with
{!$Flow.FaultMessage}, the record ID and the current user. This is how you find out about the failures nobody reports. - Sends the error to somebody who owns the flow, rather than to whoever last modified it, which is the default recipient and is frequently the wrong person.
{!$Flow.FaultMessage} holds the platform error text and is only populated on a fault path. Putting it straight in front of an end user is rarely right. Putting it in a log record is almost always right.
Who gets the email, and how to change it
By default, flow error emails go to the user who last modified the flow. That is a sensible default for a developer and a poor one for a live org, where the last modifier may have left. Process Automation Settings in Setup lets you send them to a named address instead, ideally a shared mailbox.
Frequently asked
Why does the flow work for me and fail for a user? Field-level security and record access. A flow running in user context cannot write a field the user cannot edit, and a Get Records returns only records the user can see, which produces the null that produces this error.
Can I make the error message friendlier? Only on a fault path. Without one, the platform’s own message is what appears, and you cannot change it.
Does a fault path stop the transaction rolling back? No. Records already committed in earlier elements may persist depending on where the boundaries fall, so use a fault path to report and log, not as a substitute for thinking about partial writes.
Where do I test this? Flow Builder’s debug option runs the flow with the values you supply and shows the same element trace inline, without waiting for an email. Run it as another user to catch the permission cases.
