1.1 Overview | 2 Recipes | 3 Resources from Comala Document Management | 4 Understanding the Workflow Supplier | 5 Fetching data from Comala Document Management workflows | 5.1 Example | 6 Limitations of Comala Document Management workflows

Overview

Comala Document Management provides a workflow and approval process that serves many different organizations. Using Reporting, sophisticated reports can be built to access and review your Workflow data.

This use case involves an integration between Reporting and Comala Document Management. Both apps must be installed before proceeding.

Open

Recipes

Resources from Comala Document Management

• Appfire Reporting app integration

• Workflow Supplier

• workflow-reporter macro

Understanding the Workflow Supplier

The Comala Document Management workflow supplier allows you to access Workflow data using Reporting. It is an extension of our existing set of Reporting suppliers. 

The 3 main objects supplied by the workflow supplier are

• approvals

• states

• tasks

Any page with an existing Workflow will contain these 3 objects. To access the workflow data associated with each page or space, simply refer to the keys provided by the workflow supplier. 

Fetching data from Comala Document Management workflows

Accessing the Comala Document Management workflow data is the same as any other key. Just refer to the workflow supplier to figure out what you would like to report on.

If you are an existing Reporting user, then this should be easy  

Example

Open

workflow:state>name returns the name of a page's state, this case it's 'In Progress'.

workflow is the prefix, and state is the key. name is the chained key of state.

Limitations of Comala Document Management workflows

• Under Approvals, there are 2 keys to determine approval: approved and rejected with Boolean values that are basically a negation of each other e.g. when a page is not yet approved, then approved==false and rejected==yes.

  • this is unintuitive because if a page is not approved, doesn't mean it's rejected either

  • because of this design, users will not be able to report on a list of rejected pages. The report would be a list of 'unapproved' pages instead
    
    

• Cannot access workflow:tasks or workflow:approvals directly

  • if report-info: workflow:tasks>name is done, nothing is returned

  • instead, the workaround should be:

    • {report-on: workflow:tasks}

    • {report-info: name}
      
      

• Because all workflow fields are initiated to '' when a workflow is initialized, that means all values are already a string

  • in most cases report-empty will not work

  • workaround is to have very meaningful names in the 'default value' field
    
    

• Tasks and Approvals should be accessed using a collection-filter instead of a text-filter or date-filter

  • this is because there are multiple tasks/approvals under the tasks object