Hey Jacob, unfortunately our customer is still experiencing issues.  We're currently in the process of reducing active Workflows and having some users try out the desktop client instead of the web client to see if that increases performance. 

One other thing we're going to try is to change one of their dropdown fields to be a database lookup/dynamic field instead of native drop-down field values.  This client has a "Subject Term" drop-down for all records that has over 2400 values and I'm wondering if the HTML pre-loads these drop down values for each document if they're native to the field.  Dynamic fields seem to only load values when you interact with the field but I'm not an expert at web elements so this is only a guess.  It does seem though that when they're experiencing these issues the web browsers struggle to load the web elements.  

I have an open ticket and I plan on presenting this workaround to Laserfiche and getting their input so I'll let you know what they say.  I don't know if your client has a similar situation or not.

Hi Grant,

Have you tried messing with the MaxDropDownLength attribute for the users in question? May not help in your situation, but I actually had a case where setting that attribute to 50 solved a problem involving Cloud taking forever to load a list. 

I was able to identify the cause of some of my issues from last week. We found that using Workflow to rename entries in Cloud doesn't work quite the same as it does on-prem. It resulted in entries not moving to folders they should have been moving to. Kind of requires a long explanation, but if you have entries in the wrong place and workflows that rename entries, I can elaborate. 

Hey Jacob thanks for the recommendation, does that mean that only 50 results will load at a time?  If they wanted the value that was at number 100, would they have to start typing the term out in the field and then pick from the drop down?

We do have a Workflow that performs several rename activities throughout the process although most of the time it's renaming shortcuts to indicate what task needs to be completed.  Once the task is completed, the shortcut/task is deleted and another shortcut is created for the next user task in the process.  I'm definitely curious what you found out about entry name changes that can cause performance issues

Yes, that's how it's worked in my experience. It changes the appearance of a dropdown to be a text box, and as the user types in data, it'll show a list once the number of possible choices has reached the maximum allowed by the attribute.

So this Cloud customer in question would email me to say "hey I changed this field value on this document, but the document didn't move where it was supposed to move." We'd look at the audit log of the document and see that the ProcessAutomationUser was moving the entry multiple times, and that it would go to where it was supposed to go, but would then get moved back. We eventually deduced that the 'rename entry' activity in Cloud workflow basically updates the entry's full path, rather than just the name of the entry.

So, if you have a workflow that renames an entry after moving it, there is apparently a possibility (since this doesn't happen every time) that the 'rename entry' activity will take the global entry full path token, update the last part of it (which would be the entry name), and then put the entry in the original entry path location since the entry name is just the last segment of the full path. Since this happens after the 'move entry' activity, the document appears as if it didn't move because it ends up back where it was originally. Pretty easy to fix - just make sure your 'rename entry' activities occur before your 'move entry' activities. I normally set it up that way anyway, but for some reason did it differently in this case.
 

The other situation we ran into is a little more difficult to explain. We'd have a customer who would want documents named a certain way based on field values, but the field values would get filled out gradually through the document's life. Someone scans in an invoice and provides the invoice number, then the manager fills out the total amount, and then an AP clerk would fill out the vendor information (and all of that info was desired in the document name). So we'd set up a workflow that would simply rename the document every time a document with this template was changed (excluding the workflow service account) and regardless of what else was happening to the document in a separate workflow (moving to a new location, for example), the two workflows would never conflict. But a similar combination of workflows in Cloud can cause documents to appear to not move because the workflow that simply renames the document starts a fraction of a second later than the workflow that is moving the entry. If the renaming of the document happens after the moving of the entry in the other workflow, the document ends up back in the original location. I absolutely admit that this may not be a best practice, but I've never had an issue with it in on-prem systems.

In short, in on-prem Workflow, the 'rename entry' activity appears to take the entry name as it's own piece of information and updates it independently of the entry's path. In Cloud, the entry name appears to be the last segment of the full entry path, and the 'rename entry' activity updates that last segment, and puts it back into the path it was in when the workflow started.

Does that make any sense? Huge wall of text, I know.

@████████, the above about the Workflow entry renaming activity is perhaps of interest.

Yea that makes sense.  So far as I have noticed this hasn't been occurring in our customer's environment but I'll have to take a look and see if I rename any of the documents after moving them and just move the rename activity before the move activity just in case.