What it requires. Custom error messages displayed to users from flow Custom Errors elements must be written in plain English, explain what went wrong in business terms, and avoid exposing technical detail such as field API names, element names, or system error codes.
Why it matters. Users encountering a flow error mid-process need to understand what happened and what to do next. An error message containing technical content such as field API names or internal codes causes confusion, erodes trust, and generates avoidable support calls. A well-formed error message states the business condition that was not met and directs the user to an appropriate next action.
How to fix it. Rewrite all custom error messages in plain English. State the business condition that prevented the action, avoid all technical terminology, and direct the user to a specific next step or team contact.
Is this rule worth checking?
Votes and comments are published here. We read them, and we publish what we change with the reasoning — a vote does not move a rule on its own.