DW7 AutoIndex: practical limits on number of "field has changed" autoindex workflows?-1543527786

Is there a practical limit to the number of AutoIndex workflows that should be configured for a single cabinet that are triggered off the new "field has changed" trigger?  We have a client with quite a few conditions that will result in different index fields needing to be updated, such as "if the Document Type is 'contract' and the Status is 'Closed' then update such-and-such data, but if the Document Type is 'invoice-in' and the File Title has changed then also update such-and-such".  From a quick glance, I could envision having at least 4-5 of these AutoIndex workflows looking at specific criteria, so every time an index entry is changed DW would be running each of these workflows.  Will that be a problem? Or do they just run synchronously?

Jon,
I don't think that there is any practical limit. DocuWare 7 has what is called long living processes that are there to handle jobs such as Instant AutoIndex. One of these is specifically allocated to Instant AIX, so I would think that the jobs will run synchronously.

Phil Robson
Senior Director Support Americas

Perfect, thanks Phil.

Follow-up question for clarity: how linearly are these run?  For example, if I have 6 Instant AIX workflows setup can I rely on the 1st one to always run before the 4th, to the extent that the 4th workflow can use data that the 1st will be populating? 

I need to be sure about this before I put a whole lot of work into converting an entire system over, and i don't think that building and testing this in a vm (which tends to be much more lightly loaded than a production system) will give me a good indication, so thanks for the help.

Jon,
I don't think you can rely on it. My take is it depends on the Trigger condition. How can you be 100% sure that the indexes are changed in the order you want? What if the indexes were modified in such a way that the 4th Triggered but 1, 2, and 3 had not because they did not meet the Trigger conditions?
Now perhaps you have that all planned out where that cannot happen, so the answer to the question is each time an AIX is triggered it goes in to the Task Process list. This is a fifo list. Theoretically, task 1 will be processed before task 2. But if for some reason task 1 cannot be processed it will be flagged for retry and task 2 executed. Also consider that the process may be multi-threaded and will grab several tasks at a time.

As I said, I would not rely on it.

Phil Robson
Senior Director Support Americas

Excellent info, thanks Phil.  Building the AIX workflows as if they were always running synchronously would have been the easier/simpler solution, which is always much more desirable (of course!), but I'm fairly sure I can build them individually to achieve the result I'm after so that no one workflow is relying on another one to have run first.