Because all of your branches/logic are constrained to a single workflow you will hit a concurrency limit of 4 at a time. I can't quite tell what starts your colored screenshot, but I'm assuming its a metadata conditional starting event. This isn't necessarily bad, and would be needed if you also want to change metadata from the repository client to re-trigger the update workflow. For your large batch I would recommend copying the topmost branches that define A/B/C to the workflow that loops over the entries and queries the database for the new account numbers (I'll call this the main workflow). All you need is what gets it into either branch A/B/C you don't need the logic for branch 1-X. Then I'd make three copies of you colored workflow (I'll call this the filing workflow), so you'd have filing A, filing B, filing C. You can keep them as is, even though you already know if its A/B/C at the point its invoked its minimal overhead and you don't have to worry about breaking the workflow disabling stuff. Then in your main workflow you just invoke filing wf A, B, or C from within the condition making sure "wait for wf" is not checked.

Now you should be able to get roughly 3x the speed. If A is still 2x the other quantities that will be your slowest workflow to complete, but should still be a smaller number than your original amount.

Note: I'm assuming none of this filing touches the same entries i.e., two workflows potentially running at the same time trying to create the same parent folder. If thats potentially the case and the workflow isn't built to handle that I'd say just run it how you have it now (still prefer directly invoking instead of waiting for field change) and let it run over a weekend.

We have a lot of experience processing large volumes and breaking it into smaller branches and sub-workflows is definitely the way to go. My first LF project involved migrating 40 million documents from a legacy system, and after I got the workflows optimized, we finished 6 months ahead of schedule.

Another thing to keep in mind is the number of iterations within a particular workflow instance; with each iteration, workflow tracking data will accumulate and depending on how many activities you have it can start to have a serious impact on performance after a few hundred iterations.

In general, I limit these types of workflows to about 250 documents per instance. I might have multiple instances in parallel, but the idea is that I don't want a single instance to run so long that it becomes inefficient (i.e., an activity that takes seconds in the beginning can take minutes by the end if try to do too much in a single instance).

However, I'd be extra careful if you don't check the "wait for wf" option. If you go that route you want to be very sure you're not bombarding the server with too many sequential requests because you could easily overwhelm the server if you're not careful (e.g., having people exit a plane row-by-row vs just telling everyone to get up and go at once).

I tend to prefer creating parallel branches that wait so I can create a sort of flow regulator, but that does require an extra workflow to manage the parallel branches. I also agree that directly invoking the workflow is preferable to waiting for a field change because that gives you a lot more control.

With enough resources, Laserfiche can handle some pretty serious volume, so it just depends on your environment and workflow design. For example, our main document processing workflows can handle about 5,000 documents per hour during business hours, and that's with extra steps like OCR and PDF generation.