I can't find any basic entry name in the search conditions
Chad,
The quick answer is that you can't search by entry name (with or without wildcards) in the Cloud Search Repository activity. Not sure why they omitted that feature as it sure is handy (some would say essential).
I guess they are going to have to stop putting metadata only in the file name and use workflow to fix everything. Sometimes I wish you could just remove file name as a feature from templated documents so that it doesn't enable them to do this. Once you have a template you don't need a file name, it only allows for making mistakes and causes confusion when searching (they sometimes see data in the file name that is not accurate since it was updated in the template)
I haven't been able to find a way around not being able to search via entry name in some of my workflows. I really hope Laserfiche adds this into Workflow; I guess there's a technical reason why it's not included, but I have many disappointed users because I'm unable to re-create some of my most useful workflows due to this feature missing. I've gotten more creative as a result, but the workarounds I've made in a few instances would take even more processing power. In some scenarios though, I haven't been able to find a single workaround with how stripped down workflow is in Cloud.
Michael, do the workflows you mention use exact match or wildcarded entry name searches? One reason why we don't allow entry name searches in workflow is that wildcard entry name searches are one of the most computationally expensive possible searches you can run, on the order of 1,000x more than an exact match search.
Someone running hundreds or thousands of iterations of a wildcard name search in a Workflow search has the potential to spike repository database and search service resource utilization so much, so quickly, that it would immediately impact other customers. Those backend components are among the harder ones to dynamically scale on short timeframes so we don't have a great way to rapidly mitigate the performance impact. We constantly get support cases for self-hosted system performance where the issue is one or more workflows doing looped wildcard (or otherwise inefficient) searches.
If we do add entry name searches in the future (which I completely agree are useful), they will likely be restricted to exact matches.
Hi Samuel, thank you for the great explanation. I thought that may be the case but it really helps to hear it from Laserfiche directly. Exact matches would be helpful, but I found a workaround for that (using entry path equals [parent folder name], then using a for each entry loop to check for a match provided it's <= 100 entries found).
The problem I have is our repository has a few instances of descriptors in the folder names. For example, our municipal roll files are in a format like:
12340000000
12340000100
12340000200
etc.
Then users will add an address to the end of the roll file folder to help identify it like:
12340000300 - 123 Main St
So when I try to route to that folder, I cannot do so as I have to use a search repository first, and I may not have that address to search for an exact match. I think a wildcard is necessary in this case. For now, I just move the entry into the expected roll file folder, and assume there will be the odd duplicate.
Being able to do exact matches will still be a huge help, as I have had to workaround that a few times adding loops. The wildcard searches are incredibly useful though. If it were possible, I'd be fine with Laserfiche imposing a cap on search duration if it meant we could get this feature. Or perhaps a limit of 1 result if using wildcard searches, because I find 80% of the time I'm only really looking for a specific folder to drop an entry into.