Both Flow and Process Builder have a clear UI that displays the order of the steps. It helps the user understand when the process performs the actions. Unlike Flow, there is no start condition in Process Builder. When a record is created or updated, all the processes related to that object run. Therefore, if there is more than one Process Builder running on the same object, it is not possible to know which one runs before. That is why Salesforce recommends you to have only one Process Builder per object. This is the best practice for Process Builder (same recommendation for Apex Triggers).
When Salesforce introduced the record-triggered flows, everybody got the same question in their minds. Should you have only one record-triggered flow per object? Even though it is more advanced version of Process Builder, there is a difference in record-triggered flows. You can define a start criteria, which means that if the record doesn't meet the start criteria, flow doesn't even run. Because of this, Salesforce announced that the best practice is to have multiple record-triggered flows with specific start criteria.
It is obvious that before save flows run before the after save flows. But in some cases you can have multiple flows with the same trigger type (before or after save) and the same start criteria. Or you can have flows without even a start criteria. So, which one will run before?
In the Spring '22 release, Salesforce introduced a new feature called Trigger Order for record-triggered flows. Thanks to this new feature, you can define the trigger order of record-triggered flows for an object.
Under the advanced section of the version properties, there is a new number field called Trigger Order. You can enter a number from 1 to 2,000 to prioritize the order that the flow triggers run for the specified object. This parameter determines the order that flows with the same trigger type (before save or after save) run for the same object. Using this feature, you can declaratively configure a flow to run before or after another flow that has the same trigger type. Same trigger type is critical here. It means that you cannot make an after save flow run before a before save flow.
When you define a number in this parameter, flows with the same trigger type on the same object start to run in ascending order. First, flows with trigger order values from 1 to 1,000 run in ascending order. If there are multiple flows with the same value, they run in alphabetical order according to their API names. Next, flows without trigger order values start to run in the order of their created dates. It also means that if you don't use this feature at all, your record-triggered flows run according to their created dates. Lastly, flows with trigger order values from 1,001 to 2,000 run in ascending order. Again, if there are multiple flows with the same value, they run in alphabetical order according to their API names.
What is the best practice?
Just because you can enter numbers from 1 to 2,000 it doesn't mean that you can have up to 2,000 flows for the same object. Still, try to build minimum number of flows. When entering the values, evenly distribute the numbers. For example, enter 10, 20, 30 instead of 1, 2, 3. Therefore, if you have to put another flow between them, you will not need to change the trigger order values of all the flows. You can just set the trigger order of the new flow as 15.
Trigger order doesn't affect the scheduled or asynchronous paths.
Read this article from the release notes to learn more about this feature.