qbo.Decision: Workflow Management

The qbo.Decision module represents the workflow management. Workflow is typically modeled in flow chart, where:

• • each shape represents a Step, and

  • each line between shapes represents a Dependency

Steps in a workflow fall into one of five broad categories:

• 1. Tasks: require human input, which cause a workflow to pause until completed by a person,

  2. Documents: mail merge data with a document template to produce a document,

1. If/then steps: used to branch workflow based on data conditions

   1. Polling steps: periodically query the database, waiting for some data conditions to be met

   2. Other steps: call other QBO 3 class methods

Tasks

Tasks typically present a user with a custom form, requiring them to enter data required by later steps in the workflow. 

In the example to the right, the 'Foreclosure Referral Review' step is a task (custom form) that prompts a user to verify that all required data for a foreclosure referral has been entered.

Documents

In the example, the Generate Breach Letter step invokes the qbo.Attachment module's Generate method, producing a PDF document via Microsoft Word's mail merge feature. This is done entirely server-side, and need not involve any human interaction.

If/Then Steps

The 'State Letter Required?' if/then step determine if a State Letter is required given the conditions associated with a particular workflow. If then steps are executed synchronously, and simply evaluate data points in a series of if/then statements to arrive at a 'true' or 'false' condition. Other steps can be made dependent on an if/then step being true, or on and if/then statement being false.

Polling Steps

The 'Wait for Certified Mailing' steps monitors the database for an update to the attachment's OutboundTrackingID column. Polling steps are executed on a schedule, querying the database and evaluating the results against and if/then statement. Once the data conditions are met, the polling step is completed, and the workflow may progress.

Other Steps

The FTP to Mailing Provider step invokes the qbo.Attachment module's Copy method, which can copy documents from the QBO imaging store to any configured FTP site or imaging system. In this case, the mailing provider's FTP site has been configured under the Attachment module in advance, so any document can be copied to their FTP site.

The 'Print Breach Letter' near the end of the workflow is only executed when the 'State Letter Required?' if/then step evaluates to 'true'. If executed, it leverages the qbo.Attachment module's Print interface, capable of having the QBO servers remote-print documents within our client's network.

When invoking various methods, you will be prompted to enter three key Action fields:

1. ClassName: this is the name of the QBO 3 module the workflow step will be calling (e.g. Loan, Borrower, Contact, Attachment, etc.)

2. Operation: this is the name of the module's method that the workflow step will be calling (e.g. CopyFile, Edit, Geocode, etc.)

3. Parameters: the parameter to be passed to the Operation

Decision Processing

Normally, simply saving a Decision will cause the workflow to be 'processed'. Technically, the Decision class includes a Inserted event handler that calls the Decision.Process() method, which in turn will process a workflow.

The Decision.Process() method queries the database to insert eligible steps, and for each step, either processes the step (if the step is defined as synchronous), or queues the step for processing (if the step is asynchronous).  In both cases, ultimately the DecisionStep.Start() method is being called.

For installations that are running QBO 2 and QBO 3 side-by-side, decisions must be processed with either the QBO 2 workflow engine, or the QBO 3 workflow engine; it should not be processed with both. For this reason, QBO 3 includes a DecisionProcessOnInsert application setting, which defaults to true. If true, Decision.Insert() will call Decision.Process() automatically.  If set to false, Decision.Insert() will not call Decision.Process().

Parameter Substitution

QBO 3's Parameter Substitution patterns are used for the parameters. For example, the Attachment/CopyFile method expects two parameters: and ID and a FileObject. When designing the workflow you cannot know in advance the values to be passed, so instead you represent the values as XPath expressions wrapped in curly braces.  For example:

• • Attachment/CopyFile?ID={//AttachmentID[1]}&FileObject=MailingVendorFTPSite

  • Contact/SCRASearch?SSN={//USSSN[1]}

The XPath expressions in the curly braces are evaluated against the Decision's parent Summary statement, which essentially returns all data associated with an object.

If the data containing in the parent object's Summary method is insufficient, a custom query may be used to feed parameters instead. By checking the 'data from a query' checkbox, the UI changes, and you may specify a query to run prior to evaluating the Action to take.

In the example to the right, the query being run is Attachment/Search?InDecisionID={DecisionID}.  The InDecisionID is a useful filter that limits search results to objects created by a Decision. Note that in this case parameter substitution is being used for the custom query! In this case, the parameters available are limited to the columns associated with the Decision table.

If a step uses a Query to feed parameters to an Action, the action is invoked for every row returned by the query. In the example on the right, this means that all attachments created by the workflow would be transmitted to the Mailing Vendor's FTP site.

Date Calcuations

Each workflow step can be dependent on zero or more predecessor steps, and each can be configured with an estimated duration. Normally, the Completion date = the Start Date + the Estimated Duration. 

Each workflow step includes six dates:

• • Estimated Start: the computer-determined start date of a step, determined as the completion date of the last predecessor to be completed

  • Projected Start: a human override of the estimated start

  • Actual Start: the date the step was actually started (DecisionStep/Start was called)

  • Estimated Completion: the computer-determined completion date of a step, based on a 'ReferenceDate'. If no reference date is defined, the start date is used.

  • Projected Completion: a human override of the estimated completion

  • Actual Completion: the date the step was actually completed (DecisionStep/Complete was called)

Note that reference date calculations do not occur until DecisionStep/Start is called. Thus, if you have asynchronous steps, they will initially have an estimated completion date based on the step's start date.  Once the step's Start method has been called, the Estimated Completion date will be recalculated in relation to the reference date. This is because step completion dates are initially calculated in bulk in the data tier, but the reference date calculations rely on XPath expression evaluation done in the application tier.

Step Repeatability

Typically, a step in a workflow occurs One per workflow. This can be overridden, however, to handle different use cases:

• • Multiple: this option is used for workflow steps where a user may need to trigger a workflow step manually. For example, a workflow may include an "Interim Bill" task that occurs at a certain point of the workflow, and users are allowed to inject such a step whenever they deem it appropriate.

  • Ad-hoc: this option is used for workflow steps that only occur when a user chooses to add them manually. For example, a foreclosure workflow might have a Sale Adjournment step. One would not plan a sale adjournment for a standard workflow, but wish to allow a user to add them to a workflow when real-world situations dictate.

While a task can be added at any time to a record, it is often used to "bind" a task to a specific workflow within a record. This is where multiple or ad-hoc steps become useful.

Changing Templates with Existing Workflows

As workflow template evolve, power users will need to weigh the impact of changing existing workflow templates versus creating entirely new templates. Assume we have a simple workflow comprising the following steps: