The folder move is not what is taking time.   When it goes to move the folder it is only a few 100 milliseconds.    What is taking the time is the query to search the entire repository to see if that folder already exists.   That is showing in the workflow at 15+ seconds.   Thanks!

Understood. Searches that return lots of results do tend to take quite a while. Understanding what the workflow is intended to do might help provide us with information we could use to provide suggestions on how it could be improved.

Here's an anecdotal example I can give to tell you how I fixed the slowness for a workflow that needed to run a search for, and process, over a million entries.

The goal of the primary workflow was to run a secondary processing workflow on each entry within a repository folder that contained an "Unprocessed" tag. The processing workflow would remove this "Unprocessed" tag, so they would never be processed twice. Like you, the issue was that searching for that many entries takes forever.

However, you can limit the number of results that a search returns. Because of this, I looked at approximately how many entries my workflow could process in an hour and set the search result limit to slightly above that amount. I put the "For Each Entry" activity within the primary branch of a Deadline activity. I also put an "End Workflow" activity within the Deadline branch and set the deadline to 1 hour. I then set the schedule of this primary workflow to run once a day and repeat every hour for 23 hours.

Using this method, the primary workflow's searches are considerably faster because the entries are being processed in batches rather than all at once, and the workflows don't pile up or conflict because they will always only run for an hour at a time. An additional benefit is that I can now view each workflow instance's data. This is important because, if there are too many entries in a workflow like yours, trying to view the workflow instance's data can cause it to time out and you will be unable to view the data at all.

It sounds like you may be able to do something similar, or even break it down into shorter workflows if needed.

Sure.... the workflow is designed to take a folder from one area and move it to another.   So what is does is.

Search Entire Directory to see if a folder with the same name exists.

YES:   Merge the data into the prexisting folder.

NO:    Create a new folder in the target destination.

That is pretty much it.   

Here is the search query

{[]:[Case Number]="*"} & {LF:Name="%(CaseNumber)", Type="F"} & ({LF:LOOKIN="digital-evidence\1. PROCESSED DIGITAL EVIDENCE"} | {LF:LOOKIN="digital-evidence\2. DISCOVERY OPEN - CA"} | {LF:LOOKIN="digital-evidence\3. ATN RETURNED"} | {LF:LOOKIN="digital-evidence\4. ARCHIVE"} | {LF:LOOKIN="digital-evidence\2. DISCOVERY OPEN - DA"} | {LF:LOOKIN="digital-evidence\5. PURGE"} | {LF:LOOKIN="digital-evidence\6. REMOVED FILES"})

Here is the activity from the Workflow. 

I just ran a little test to see if I could find a more efficient search method, and I think I have.

If the %(CaseNumber) folder is always a child of one of those folders you are searching within, you should add "SUBFOLDERS=0" to your LOOKIN statement. That should shave some time off. For example, {LF:LOOKIN="digital-evidence\2. DISCOVERY OPEN - CA", SUBFOLDERS=0}

What is the purpose of having {[]:[Case Number]="*"} in the search? Is that to ensure the field is assigned and not blank? If you don't need to check that value, remove it from your search altogether and see how that impacts the time.