We recently finished conducting a technical proof of concept with a financial services client. One of the big discussions was workflow, specifically a queue driven approach with workflow templates versus a form driven approach with dynamic workflow. Since either approach could satisfy the client’s requirements in one way or another, the client wanted us to compare and contrast the different approaches. This post will summarize some of the key differences.
Form and Workflow Background
To clarify, forms are often a part of workflow processes. Forms are typically used to capture data from users in order for the workflow engine to make routing decisions. Whether implemented using the forms module of Documentum xCP or our Active Wizard open source product, at some point in time, information outside of what is contained in the documents attached to the workflow needs to be accessed by the workflow engine in order to make decisions.
Here is a quick example:
- The client is processing a request for information regarding a contract. The request is sent in via fax. In this instance, the document (fax) is a PDF that may have some metadata (e.g. date received, sender name), but the core processing for the request for information is in building a response to the request. The workflow would probably include the request document as an attachment, as well as other information about the contract or response that could drive the workflow process, such as the contract dollar amount, type of response required, due date, or other required information. Attaching a form to the workflow could streamline the workflow initiation process by prompting a user for this information. The contract dollar amount field could drive which users need to act as approvers in the workflow. The type of response required might drive which users need to participate in creating the response.
In the example above, the workflow to move the processing between resources and monitor the process would rely on information from both the form and documents attached to the workflow.
Workflow Template – Queue-Based Approach
In a typical queue-based approach, the process might work like this:
- The request for information comes in as a document and is assigned to a workflow template (by a person or some automated method).
- A resource could choose or be assigned to process the request.
- The same resource would complete the form.
- The workflow template would interpret the form (diamond icon in many of the workflow template tools) and determine the next resource assigned to work on the response.
- Based on the contract dollar amount and/or type of response required, different resources would be added to the workflow to complete tasks in order to build the response or approve the response before it is sent out.
Below are some key points to consider with template driven workflow:
- All workflow needs to be contained within the template – In the example above, if a certain contract dollar amount triggers a different approval cycle, that workflow path would need to be defined in the template. A resource would be assigned to manage all of the templates, usually a person with some level of IT background. The workflow template might get very complex depending on the business rules, and might even need to be split into multiple templates.
- Any changes to the business process require workflow template changes – In the example above, if the contract dollar amount threshold that is used to determine who approves the response document changes, then changes must be made to the workflow template. This usually involves an IT request.
- The users involved in the workflow aren’t known until each workflow rule is triggered – In the example above, all of the information needed to determine the participants in the workflow is available at the time the workflow is initiated. However, the workflow participants are unknown to the user who is initiating the workflow because the routing decisions are made downstream by the workflow engine.
Dynamic Workflow – Forms Based Approach
In a dynamic workflow approach, the process is somewhat different.
- The request for information comes in as a document and is assigned to a resource (by a person or some automated method).
- The resource would complete the form.
- The form builds a workflow template dynamically based on how the form is filled out, assigning people or groups based on the data from the form.
- Based on the form answers, different resources would be automatically included in the workflow to complete their tasks or approvals.
Some key differences to consider with dynamic workflow
- No workflow templates – A basic template might be constructed for pre/post business rules, but the bulk of the workflow template would be built on the fly based on how the form is completed. Instead of templates, the dynamic approach focuses on building business rules to construct templates on the fly, rather than building business rules into a template.
- Everyone involved in the workflow is known at the beginning of the process based on the business rules – In the example above, the user who fills out the form and initiates the workflow can easily see the users and groups that will participate in the workflow before it is started. This allows the initiator to understand the routing process, verify that the form was filled out correctly, and make adjustments prior to kicking off the flow. A good example of how this might be useful is if the person initiating the workflow notices that one of the assigned workflow participants is on vacation. In this case, the initiator might be able to edit the form and in a way that the person on vacation will no longer be a part of the workflow.
At TSG, we lean toward form/dynamic workflow more than template/queue based approaches based on our experience for many reasons, including:
- Dynamic form based workflow can be used to generate workflows that follow a queue based approach if needed. However, workflow templates must contain all possible workflow branches in order to be dynamic. If business rules change, an IT request is necessary to update the template. Very complex systems, or systems with many forms can be challenging to manage over time.
- Clients like to “see” who is involved in workflow before the process is started to better monitor the process.
For additional discussion of the Active Wizard’s approach to dynamic workflow, read this post. More information is also available on our website and demonstrations can be viewed in our Learning Zone. Let us know your thoughts or experiences below.
In the Dynamic forms approach won’t the business rules (instead of the workflow template) require updating when things change?
The Active Wizard is a dynamic forms application that is an open source offering from TSG. The Active Wizard has an administrator interface that allows users to create and modify the rules that drive the dynamic workflow routing. This interface allows non-technical users to manage the workflow without the need for modification and deployment of workflow templates or code updates. You can see a demonstration of the Active Wizard workflow and admin module here https://tsgrp.wpengine.com/multimedia/TsgLearningZone/TsgLearningZone.html?itemName=ActiveWizard&demoId=1
To expand on what Tony said, one of our clients uses the Active Wizard for over 400 forms, each with a potentially different workflow process. Managing hundreds of workflow templates would have been a nightmare to maintain and update over time. However, using the Active Wizard’s rules based approach, business users can manage their rules and workflow processes without getting IT involved.
So, yes – you’re absolutely correct. When business rules change, something needs to be updated with either approach. The key is who can do it, and the level of effort/resources that it takes to get the change implemented.
Jorge Sapaj says
Wouldn’t this kind of scenario get solved using aliases for performers based on rules/scoping instead of managing 400 forms?
Have you seen EMC’s EPFM framework for Webtop? It seems to solve the same issues covered on this article.
The 400 forms were not created to solve workflow problems, they are actual corporate forms that the client uses in their business every day. No matter how you design the workflow for these forms, you still have over 400 of them.
You could certainly use aliases and a few complicated workflow templates to get this to work, but the issues mentioned in the article above are the exact reasons why this client chose the Active Wizard’s dynamic form approach – they didn’t want to require IT involvement to tweak templates as business rules change.
Jorge Sapaj says
Understood. I was thinking the forms where built for cover different workflows scenarios as the main article subject is. From your reply, I now see that they where meant for data primary….
Thanks for your response.