Workflow: Understanding the start trigger...-1521828270

Hey all,

Quick question about Workflow Designer... I find myself starting most workflows by having them trigger when any new document is added to a file cabinet. But even when just asking for all new documents to kick off a flow, one has to put a condition in before the "Start" can be saved.

So, I find myself doing things like making a condition that says Doc ID > 0, or some other condition that will always be true.

Why can't we just have the Start trigger be storage of a new document, period? It seems odd to have to make up a tautological condition just to start the workflow. I want it to simply start and I will apply Conditions and Tasks from there.

Am I mising something or not wrapping my head around the "right" way to be doing this? What conditions do other people use on triggers to simply statt the work flow for all new documents?

Thanks,

Joe Kaufman

Joe,
The parameters New document or Changed index values are the basis for the trigger. So you can trigger on New documents only, Changed documents only, or New and Changed documents.
So that's the first part. Now you must specify an index value(s) to monitor. Suppose you have a file cabinet with Invoices, Purchase Orders and other miscellany in your cabinet and we simply triggered on New documents, but your workflow is for Invoices. You would end up with all other document types in your workflow that are not valid.
Therefore you must differentiate between documents that must start a workflow instance and those that should not. So you cannot just have a trigger based on the storage of a document.
A typical trigger would be:

New documents
Index field Status = "New"
Index field Document Type = "Invoice"

Phil Robson
Senior Director Support Americas

Phil,

I see your point, but we almost never use one file cabinet for documents as disparate as AP and AR -- an AP invoice (puchase order) is going to probably have different fields than an AR invoice (sales order), for example. We like to keep our structures as refined as possible, so we segment our document types a great deal even when some index fields overlap.

I guess what I am asking for is that the condition requirement be eased for when you are in "new document" mode (only). In essence, that would give you three basic scenarios:

1. All new documents.
2. New documents meeting some condition(s).
3. Index changes meeting some condition(s).

All without needing to dummy up an "everything" condition like "Doc ID > 0". Luckily, exposing the system fields makes it very easy to create a catch-all condition.

Your point is also very valid in the event, for example, an already-reviewed document gets stored. In that sense, a no-condition trigger could be found to be a bit overzealous, and the user should probably be warned if they create a new-only, no-condition Start. Then again, a quick COndition at the start of the flow to route a document to the End if it is already found to be completed would handle the situation.

At least I am not crazy in having to make these always-on conditions, and I understand why it is easier for Workflow to just enforce at least one condition to make sure the user knows what they are getting themselves into...

Thanks,

Joe Kaufman

Joe,

as file cabinets are mostly used for a lot of different types of documents, we are thinking, that the idea of starting the same workflow for all new documents is not the normal use case. This might be different in your use case but for most of our customers it is not.

That´s why we decided to not have a generic trigger for all documents.

I don't think you can get that generic and have it work well for you. I understand what you are trying to do but there has to be some kind of input from a person on the front end (populate index fields when storing) or have a person enter some kind of input in the tasks (populate index fields within the task) in order for conditions to be met and the workflow to know what to do with the invoices. 

I don't like building a workflow that has too much activity in it so I created different workflows for different types of invoices. In a few cases, some invoices are stored in completely different cabinets because of the differences in index fields needed for certain types of invoices. 

If the workflow gets too big, I will break it down into multiple workflows and have it process certain things in the background and even start completely different workflows to segregate invoices into different tabs under Tasks.

David,

I think we come at things from a very different perspective here. Our installation isn't something assembled by end users and resellers/consultants who, no offense, may or may not have a full understanding of proper data modelling. That is not the case for us. We have developed document types that are fairly well normalized. We do not mash a lot of different document types into one file cabinet and then separate them by a "document type" index. To me, that defeats the whole purpose of separate file cabinets and breaks almost all rules of proper normalization. If you need to add a "document type" index to your file cabinet, as Steve Jobs might say, "You're doing it wrong."

There is another reason for not mashing unalike documents into one file cabinet -- parent/child relationships. What if one document type occurs multiple times as it links to a parent document type and you want to make a linkage for it? You can't do that if everything is all in one file cabinet (at least I don't think you can, and if you could it would get real ugly, real fast). That's just another reason for normalization.

Whether or not a document is "unalike" another is, of course, the whole question here. It is the foundation of all data modelling, deciding what should be considered a separate data entity. If two documents share 90% of indexes, then yeah, perhaps we do some sparse indexing on that and have holes in some documents and different holes in others. In such cases we would not use a generic trigger. But if I have a file cabinet that is as specific as "HR - Wage Tax Register" and those documents are unique, then the workflows I build against that file cabinet are going to be very simple because the documents are already inherently distinct.

As far as how documents get into the system, that is highly regimented for us as well: we use scan sheets and tend to do almost everything "after the fact". We don't scan in a purchase order as soon as it is printed and then later attached the AP invoice and check to it. The invoice and PO data all go in together, and then the check goes in later and links back to the AP invoice via automated processes written behind the scenes. I see all the sales videos for DocuWare where people scan in a sales order, then the pick tickets, then the packing list, then the BOL, then the invoice, then the payment record -- and I have no idea how folks can trust that they have all the data they need in the right spot. If something doesn't index properly, who verifies that? If someone goes in six months later and cannot find the invoice, how is that handled?

We wait until the sales order is closed, slap a scan sheet on all materials for the order (sometimes 100+ pages) and scan that into our sales order/AR file cabinet. Then, our folks go page by page and make sure everything scanned in correctly. It doesn't stop there. We then run a homegrown application that matches indexes in DocuWare to systems whence the documents came from to see if we have any documents with improper indexes as well as detecting when something in our systems has no scanned materials on record in DocuWare. Consider that Auto-Index on steroids, since it can work against our Foxpro data (Auto-Index cannot work for that -- I know it cannot because there is no reliable ODBC driver for the latest Foxpro DBF file format).

I know that all sounds burdensome (and it is), but it has been in place for years (in Fortis before DocuWare) and at this point I cannot fathom trusting any other methodology to know we for sure have documentation for all of our important processes readable and stored. If we didn't do that? If we used DW printer, and Connect to Outlook, and intelligent indexing and just threw documents all over the place into DocuWare? I can't say I would trust that because our users don't check logs etc. and they ignore error warnings (or just don't see them). We had TWO MONTHS were our production folks were scanning in documents and it was erroring out every time because their destination was set to "Inbox" instead of "Auto Identification" and they didn't have an Inbox. Those documents never got into DocuWare because they were not checking that the documents made it like they were supposed to. We were just lucky we still had the hard-copies back that far (and I have since given them an Inbox and told them they need to check). They had not been checking the scan log and left the scan unattended so missed the popup stating the job had failed (might be nice to show a counter with failed jobs over the little button that displays history – not that they would have noticed that, either…).

Anyway, that is a very long-winded way of saying I think we implement things a bit differently than most people because we have always done things from an on-site, custom programming mindset. Our file cabinets are all carefully designed and normalized to the best of our business-process knowledge. We still have some cabinets we set up a bit funkily, but it all works. And we can always set up a DocID > 0 trigger to get all new documents, so it is no big deal. I just want to make sure folks understand there is definitely a reasonable rationale behind the desire for a generic "everything" trigger, and it doesn't complicate workflows because we have already designed those complications away via (what I consider) proper file cabinet structuring.

Thanks,
Joe Kaufman
 

Joe, come on man..." Our installation isn't something assembled by end users and resellers/consultants who, no offense, may or may not have a full understanding of proper data modelling". That is a bad statement, and you should refrain from casting yourself as better than others. You're stuck in Fortis' mindset, and while the way you set your DocuWare structure up works for your company, which is great, it's the most cumbersome thing I have ever heard.

I guess I am way confused here. Because you don't have document types, you are saying that your AP Checks, PO's, Packing Lists and Invoices are all in separate cabinets? I can't imagine starting a workflow on every new document in a cabinet. Our AP file cabinet has invoices for items that are inventory items and don't need approvals and items that would be non inventory items, which would need approval. I am sure everyone does it differnet but accounts payable is accounts payable. You need your 3 way matching in most cases.

Kyle,

I shouldn't have lumped consultants in there, at least not in the way I meant, so I am sorry about that (if that is the camp you fall into). But I will say I know most end-users need help with things like normalization and data design. I am not going to apologize for saying I am "better than" most end users at that -- because I am and should be; it is my job to be. And from the experience side, we do have one area where we are allowing a department to build their own cabinets and flow, and we have already seen spots where things are not constructed in a way conducive to scalability and ease of use.

I am not stuck in any mindset -- certainly not a Fortis one -- because DocuWare is MUCH better than Fortis as it does away with all the complexity of database locations and document types. After converting to DocuWare, I will never understand why Fortis over-designed in that way (though it does do two things better than DocuWare: identifying scan sheets and complex linkages). As far as our processes being cumbersome, it is the way we run our business based on the requirements leadership dictates. We can't have a single page mis-scanned and we can't have a single document go missing. How is it "cumbersome" to have a system in place that assures that? How do you assure it for your company (or the companies you consult for -- I am not sure if you are an end-customer or a reseller/consutant)? Are you saying nothing has ever been wrongly indexed or had a page scan in badly that gets missed? What sort of processes do you have in place to make sure every closed PO or AR invoice has all materials properly on file in DocuWare? Is it because every piece and part is part of a Workflow and so must exist by definition? That is fine, but understand we don't have Workflow yet (this is just a trial) and implementing Workflow for all of our processes would involve an entire ERP implementation -- we aren't there yet. That's not due to my mindset, it is due to where the company is at as a whole.

As I concluded in my previous post, I am not saying our way is better or anything like that. It is the way we do things, and is the reason I wondered about a catch-all trigger in the first place. I do realize that a full embrace of Workflow would completely change the way we we flow documents and could very well make all of my questions moot, but I am still going to ask so that I can help the people testing Workflow understand things as they are learning. I want to be proactive on that and stay ahead of whatever direction they might want to go.

Nothing personal against you or anyone else, and it was not my intention to sound "right" or "better".

Thanks,

Joe Kaufman

Casey,

You are not confused, our processes are just very foreign to Workflow because we have never used Workflow (or any sort of "real" ERP integration) before. We have two types of documents in the system right now, primarily: scanned in stuff and then documetns for this new area that wants to play with Workflow. The former documents are catch-all. An AR invoice document has everything in it because it is scanned in when the order is done (we have a sales order system that handles data entry, approvals, notifications, fulfillment, etc.). We also have a PO system that handles approvals, thresholds, etc. etc. 

The latter documents, though are going to be more Workflow-y (at least I think they will) coming in from emails and other manual uploads. Like a query from a customer about technical services. Every customer inquiry needs to be addressed -- think helpdesk system. So, if they are asking about SKU 12345, the system will have lots of information on item 12345, and we can link file cabinets to the customer's query. That query then will go through various stages of approval and even adding data to the document (not sure if we will use versioning or not) until the query is resolved.

There is no document that we will not want to process because the query sets off the Workflow every time. I do see what people mean in that surely some aspect of the query means it will route to one place or another, but I am not sure that will always be the case. They may need to all route through a single tech info specialist to be (human) intelligently sent to the right spot in a secondary Workflow step. I am not entirely sure, as we are letting that department figure out Workflow enough to see if it is what we need or if we can just get by with Task Manager (notifications are the first main thing we need).

Like I said, you aren't confused, you are more likely in Kyle's camp and would simply find our processes "cumbersome". And I wouldn't argue with your opinion on that except to say it isn't cumbersome for us and is dictated by not ever having had anything like Workflow or a fully integrated ERP system in the past. And that's why I asked about "always on" triggers in the first place.

Thanks,

Joe Kaufman