If you followed along our podcast Episode “7 Years of Process Reports“, you already know a few things about process reports in general, and task reports in particular. In this post, I want to dive a deeper into the details, and the dependencies between process, user input task, task interface, and task report.

Task Information

An organization that understands the value of business processes, and how to build a process, in Appian preferably, that pulls people into the process using tasks, quickly finds itself in the mids of an interesting problem.

When people work with a single application, there is some kind of landing page which shows al necessary information for that specific app. This typically includes a task report with information tailored to the specific processes.

And when people work with multiple apps, what do we do then? Do we make people “enjoy” switching between apps, hunting for new tasks to complete? I hope not.

Appian already had a solution for this, called Tempo. I have the feeling that most developers and customers did not understand the power of this idea, and just wanted to build something custom for the one app they are working on. Then, years later, some started to build a separate Site to provide a unified dashboard across all apps.

Global Task Report

Now, let’s assume we are building such a central dashboard.

As a user, I would want to see all the tasks from all applications I work with, to meet the service-level agreements of the processes, and my personal performance goals.

Now, what does this mean when looking at task reports? It means that there is only a single task report. And it means that this report has to show all the relevant information from all tasks from all applications, with a fixed number of columns.

Now, you might want to throw in the towel, and switch to database tasks. Or, you follow along my writing, and understand the tools you already have at hand to make this central task report a joy to use, and easy to implement.

Process & Task Data

First, we need to look at the data we have available. First, we have the process model, and the process instance. The model has the two static properties, “Process Model Name” and “Description”, and the dynamic property “Process Display Name”.

Then, there is the User Input Task, again with two static properties, “Name” and “Description”, and the dynamic property “Task Display Name”. And, each task needs a deadline! During process execution, we also have available task status, priority, and received date.

Static means, that these properties are defined at design time, and cannot include any dynamic values from process execution. And the dynamic properties can, and should, include dynamic values from the current process or task context.

And then, there is the task interface. It has a label and instructions, which can both be dynamic. Did you ever consider to user the same values for “Task Name” in process and “Label” in the Interface, and “Task Description” in process and “Instructions” in the Interface? Well, now you do 😉

And while not relevant for this task report, never forget to add a “This Happens Next” to the end of the task form, to tell the user what happens after clicking “Submit”.

So, to populate our task report, we have available:

• Process: Name, Description, Display Name
• User Input Task: Name, Description, Display Name, Deadline, Status, Priority

Creating the Report

To create your report, duplicate the existing system report “Tasks for User”. For details on prebuilt system reports, click here.

I define my process like this:

The columns are:

• Task: tp!name & " (" & tp!description & ")"
• Subject: tp!display
• Received: tp!starttime
• Due Date: tp!deadline
• Process: pp!name & " (" & pm!description & ")"
• Priority: tp!priority
• Status: task_status()
• Sort: 2 - tp!priority & text(tp!deadline, "yyyymmddhhmm")
• Assignees: task_assignee_owner()

Make sure to filter only active tasks. We would rather not show any completed tasks.

So much for the definition. A mix of static and dynamic values should allow you to provide all necessary information to your users.

Use the “Subject” column, fed by the “Task Display Name”, to tell use user about which specific case, request, or matter this task is about.

Make sure that the “Task Name” and “Description” match the “Label” and “Instructions” of the Form Layout in the Interface. In case you use translation sets, be aware that translations do not work in process context, and you have to maintain the strings twice.

Keep in mind that working with tasks actually means “Always pick the first task in the list!”. You have to make sure to sort the tasks in a way it supports the performance targets. This is what the “Sort” column is about. Sorting in ascending order, makes sure to group by priority and sort by due date. Use escalations in the User Input Task to control the priority.

The function “task_assignee_owner()” returns the list of assignees before the task is accepted, and then the user who accepted the task.

The Real Challenge

OK, that was the easy part. And it was meant for you, the Appian Developer.

Now something for you, the corporate decision maker. You have to make sure that all Appian projects in your organization follow this exact pattern! Develop a center of excellence for Process Excellence, Change Management and Digital Transformation, define a vision, get it supported & funded, and grant it the necessary decision power. And no, this is not something any technology can help you with, not even Appian.

Thanks for reading, and let me know your thoughts in the comments. Rock it!