See Triggers and Order of Execution in the Apex Developer Guide. When a record is being saved to the database, you'll notice that item number 2 is as follows:
- Loads the new record field values from the request and overwrites the old values.
If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:
- Compliance with layout-specific rules
- Required values at the layout level and field-definition level
- Valid field formats
- Maximum field length
When the request comes from other sources, such as an Apex application or a SOAP API call, Salesforce validates only the foreign keys. Prior to executing a trigger, Salesforce verifies that any custom foreign keys do not refer to the object itself.
Salesforce runs user-defined validation rules if multiline items were created, such as quote line items and opportunity line items.
Next, Before Triggers fire, then Item number 4 occurs:
- Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce doesn't run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.
A record doesn't reach Process Builder until Item 13 on the list of 20. If a record fails validation or any item on the list, it gets "rolled back" and never gets committed to the database. It seems that you're mistaking Validation Rules for Workflow Rules. Workflow Rules cause AfterUpdate triggers to fire again on records once and only once if they result in a field update (see items 10 and 11).
What you want to do (if anything) is to cause another workflow rule to fire. Better yet might be to create a visual flow that runs for this entire process so that both fields can entered properly without needing to have the record saved twice. Another option would be to create some kind of flow that runs when that field is empty. I'm not quite certain how you'd "trigger" the latter since it would require user input. At one point there were "flow triggers" which would run just like regular triggers to populate fields without user interaction.
With all that having been said, your message sounds like you're not creating any error handling in your flows to allow them to pause or recover when interrupted. You might want to look at Sample Flows that Wait for Events in the Visual Workflow Guide for some additional guidance and examples to help you solve your issues.