Reporting on Comala Workflows data

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

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

Recipes

Resources from Comalatech

• ServiceRocket Reporting Integration
• Workflow Supplier
• workflow-reporter macro

Understanding the Workflow Supplier

The Workflow Supplier created by Comalatech allows you to access Workflow data using Reporting. It is an extension of our existing set of Suppliers. 

The 3 main objects supplied by the Workflow Supplier are: approvals, states and 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 Workflows

Accessing the 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

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 Workflows

1. 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.
     
     
2. Cannot access workflow:tasks or workflow:approvals directly. 
   • If report-info: workflow:tasks>name is done, nothing would be returned.
   • Instead, the workaround should be:
     • {report-on: workflow:tasks}
       • {report-info: name}


3. 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.
     
     
4. 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. Chaining a collection:first to task is unintuitive and bad UX.