Workflow extender plug-in

The workflow extender plug-in provides features to programmatically customize workflow automation like adapting routing based on document metadata or database queries. The optional plug-in is available for systems starting with version 16.2.

  • Automatically choose which workflow to start - Normally a workflow is started based on a user selection or predetermined configuration. This option can override the workflow selected by the user or default configuration. This is useful when the documents metadata or related values indicate the correct business process required to process the document. 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 have 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. This feature is also allowed to prevent a workflow from starting and can check that all correct conditions are present before the workflow is started.
  • Automatically choose workflow participants - Sometimes workflows only differ by a participant in a specific activity and without the plug-in this can be handled manually through ad hoc initiation or 1 of X processing. The plug-in makes it possible automate the selection of participants according to the specific needs of the documents in the workflow as the workflow is executing. For example, expenses must be approved by an employee's manager. The user simply adds the expense report to FileHold and the plug-in automatically chooses the correct manager to route the approval to.
  • Automate optional activities - Approvals often have optional activities can can be bypassed in many cases but required in others. Instead of creating a workflow template for every scenario that the initiator must choose, 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 an expense, 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 cause them to be automatically bypassed when those steps are not needed.
  • Automate observers - 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.
  • Add supporting documents - Supporting document can be helpful to the workflow approvers to provide extra context when reviewing the main documents. The plug-in is able to automatically select and add supporting documents. For example, document in the initiators document tray or documents with matching purchase order numbers, etc.
  • Copy documents - There are a variety of reasons to make copies of documents at the end of a workflow. These copies might be of main or supporting documents in the workflow or templates stored elsewhere. For example, there is a business process to setup a new customer in the system. Each customer requires a certain set of documents to be prepared for them to become a new customer such as contracts, service guides, etc. The plug-in allows copying arbitrary documents to fixed or auto-filing based locations with arbitrary metadata values set.
  • Chain workflows - Generally when a workflow ends, the process is complete but sometimes it is just one step in a larger process. For example, workflow one is used to process a request for services and workflow two is used to approve the request. In the first workflow the request document is the main document, but it is only a supporting document in the service approval process. Chaining allows the first workflow to specific that the second workflow should be started when it complete and lets it add the necessary main and supporting documents.
  • Start workflow from event - Events in FileHold can be used to trigger notifications for many activities, but the user receiving the workflow must manually initiate a workflow where needed. This feature automates this process configured on an event by event basis. For example, contracts with vendors may need to be renewed when their term is up and an event can provide a warning when this time arrived. The process to approval or decline a renewal is a perfect case to use a workflow and automating the starting of the workflow eliminates user error and delay. It might be desirable to approve the deletion of documents with the control of a workflow before the actual deletion. The following scenarios are possible:
    • Start one workflow per document as the main document.
    • Start one workflow for all documents in a schema as the main documents.
    • Start one workflow for all documents in a schema as supporting documents. Automatically create a main document.
    • Do not start a workflow, but execute some hybrid SQL code.