Reporting on Comala workflow data

Overview

DATA CENTER

Comala Document Management Data Center provides a workflow and approval process that can be used to support automated document management and approval processes in many different organizations.

Using Appfire Reporting, sophisticated reports can be built to access and review data from your applied workflows.

Both apps must be installed before proceeding.

Recipes

Resources from Comala Document Management

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 contains these 3 objects.

To access the workflow data associated with each page or space, 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. Refer to the workflow supplier to figure out what you would like to report on.

This a straightforward task for a user with some experience of the Appfire Reporting app.

Example

workflow:state>name returns the name of a page's state

  • in this case it is the In Progress state

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 negate 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, it does not mean it's rejected

    • because of this design, users cannot report on a list of rejected pages

      • the report is a list of 'unapproved' pages

  • 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 does not work

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

  • Tasks and Approvals are 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.