Workflow routing plug-in

The workflow routing plug-in provides four options for automating the routing of a workflow based on the results of an SQL script. The option plug-in is available for systems starting with version 16.2.

  • Start a new workflow to replace the workflow that is being initiated. This is useful when the workflow activities might be dependent on a value or series of values in a document’s metadata. For example, a human resources request form might allow a user to select a variety of services offered by HR, such as requesting a leave, a pay advance, a change to tax deductions, etc. Each type of request is serviced by a different part of the department. Some a very simple list of workflow activities others a complex series of approvals. The plug-in would be configured to check the request type and select the correct workflow template to initiate. The generic request template that was already initiated would be ended and the correct one would be active.
  • Sometimes workflows only differ by a participant in a specific activity. Often this can be handled through ad hoc initiation or 1 of X processing. This feature allows the possibility to automate the selection of participants. The selection can even occur after the workflow has started. For example, the first activity in the workflow assigns someone from the operations team to gather all the necessary documents to complete the remainder of the workflow. In addition to getting the documents ready the operations team will set the department metadata field on the documents. The plug-in will use this department information to select the correct users that will approve subsequent workflow activities.
  • Approvals often require additional activities depending on some criteria. Instead of creating a workflow template for every scenario an administrator can override the unnecessary activities. Now the plug-in can automatically override these activities. Continuing with the above example, imagine if there was a dollar amount associated with the documents such as for a contract or an invoice. Often higher dollar amounts require one or more addition approval steps. For example, purchase orders over $5000 require director approval, over $100000 requires VP approval and over $1 million requires CEO approval. Activities can be included for the director, VP and CEO levels, but the plug-in can automatically override them when not needed.
  • By default, the number of users that can view a workflow history is limited to those users that are or were directly involved in the workflow. Additional users can be granted access by giving them observer status. The problem comes when this permission will be granted according to a metadata field or other condition that varies from document to document, like department. The plug-in can automatically assign observers when the workflow is initiated. For example, a workflow normally has activities carried out by an operations team who adds the document. However, the document is related to a salesperson’s account and they would like to see the status of the workflow as the document is processed through the workflow so they need to be an observer. The metadata associated with the document specifies the territory and therefore the salesperson.