Salesforce Scheduled Flow – Best Practices for Bulkification

In this case, the testInvokable method is combining the results of the soql query into a single list of names. This means it only ever returns one result regardless of how many firstNames are provided.
To get the output you're looking for, you'll want to create a list of last names returned by the query specific to each first name. This ensures that the number of outputs aligns with the number of inputs.

Here's an example

global with sharing class TestInvocable {
@InvocableMethod(
        Label='Test invocable'
        Description='Return a list of user last names by passing in a first name.'
        Category='Testing'
)
global static List<List<String>> testInvocable(List<String> firstNames) {
    Map<String, List<String>> mapLastNamesByFirstName = new Map<String,List<String>>();
    for (String firstName : firstNames) {
        mapLastNamesByFirstName.put(String.escapeSingleQuotes(firstName), new List<String>());
    }
    List<User> users = [
            SELECT Id, FirstName, LastName
            FROM User
            WHERE FirstName IN :firstNames
    ];
    for (User user : users) {
        mapLastNamesByFirstName.get(user.FirstName).add(user.LastName);
    }
    
    List<List<String>> results = new List<List<String>>();
    
    for(String firstName : firstNames) {
        results.add(mapLastNamesByFirstName.get(String.escapeSingleQuotes(firstName)));
    } 

    return results;
}

}

My opinion ..

Unless I'm missing something, unlike Process Builder, flows don't appear to have a way to build a decision tree where records are sent to the "next" condition after processing the logic of the last condition. Instead, the Condition element in Flow Builder says that it will "execute the first one whose conditions are met". Is there a way I'm missing that would allow me to combine these 3 workflows into a single before-save flow which conditionally executes different/multiple before-save logic blocks on the list of records?

A: What you have to do is remove the entry criteria for the Before-Save FLOW and replace it with three Decision Elements in the Flow Canvas. You are correct in thinking these are like a before trigger.

Am I oversimplifying this by thinking that multiple before-save flows to replace these existing workflows isn't a huge concern since this is all happening before-save and not creating recursive DML?

A: Since, like triggers, code order is important, you may want one of the before save operations to set values that another before save operation on the same record relies on. Hence, move the logic to the canvas and out of the entry condition

Is the unknown order of execution for the multiple flows the only thing I should be concerned about, and isn't that a pre-existing concern for the workflow rules anyway

A: True, but with workflows they caused DML to occur and before-save Flows do not