Validation and Error Handling
Rules versus feedback
Required and unique are model-level rules evaluated at commit; a violation throws an exception, not a friendly message. Validation feedback is an activity that attaches a message to an object attribute and adds it to the object's validation set. It does not stop the microflow, does not roll back, and is only displayed when the object is on the page.
The standard pattern
Validate first, call Validation feedback once per problem, then route the flow through an error event with Custom without rollback to return to the page. For technical failures, log with Log message at Warning or Error including the stack trace, and show the user a generic message.
CoreException
Wrap commits in error events. A unique-constraint violation arrives as a CoreException; convert it into validation feedback on the offending attribute so the user sees a field, not a stack trace.
Worked example
SUB_SaveCustomer retrieves Customer where Email = $Customer/Email. If a record exists it adds validation feedback Email already in use on the Email attribute and ends through Custom without rollback. The commit itself sits inside an error event that logs the exception and adds Could not save, please retry. Reasoning: the pre-check gives a good message normally, and the error event covers the race where another user commits the same email between check and commit.
Traps
Expecting validation feedback to interrupt execution; rolling back a new object after adding feedback (rollback removes the object and its messages); validating only on the client; swallowing an exception and still reporting success; showing raw exception text to end users.