Documentum Workflow – Queue/Template versus Form/Dynamic Approaches

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:

1. The request for information comes in as a document and is assigned to a workflow template (by a person or some automated method).
2. A resource could choose or be assigned to process the request.
3. The same resource would complete the form.
4. 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.
5. 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.

1. The request for information comes in as a document and is assigned to a resource (by a person or some automated method).
2. The resource would complete the form.
3. 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.
4. 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.

Summary

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.