The Field Guide to Agile Taskflow Design

In this field guide you will learn a number of repeatable steps that can help you discover, understand and organize the tasks and taskflows needed to accomplish a specific goal.

You can either read this post, watch the instructional video below or work through the slides.

Watch the instructional video:

Work through the slides:

Get started on designing agile taskflows!

Key definitions used in this guide

A task is a specific action (operation). E.g. gather information with an online form or send an email or make an entry into a Google spreadsheet or generate a PDF.

A taskflow consists of tasks strung together to achieve a desired goal.

A taskflow app consists of a “packaged” collection of taskflows to be used by an intended target audience. Over and above the taskflows it includes user account management, access control and billing.

The steps of designing a taskflow

1. Begin with the end in mind

Start by determining what the goal is that needs to be achieved by this taskflow. Write it down on a sticky (Post-it®) note.

Secondly, how would you know when the goal has been achieved? Write down your answer underneath the goal.

To help you better understand how to design a taskflow we will make use of a case-study: the design of a purchasing taskflow app for a company with 100+ employees – to manage the purchasing of stationary, PCs, furniture, etc.

The goal

The goal is “to order and receive items”.

How would you know when the goal has been achieved? When the order has been delivered, paid for and the company policies have been adhered to.

2. Identify individual tasks

Jot down, on sticky notes, each individual task needed to achieve the goal. A task should only perform one specific action.

Indicate on each sticky whether the task relies on human interaction (e.g. an electronic form that gathers information from a human) or is automated (sending an email, generating a PDF, adding a row to a Google spreadsheet or getting a person’s contact details from another system).


When you write down the task, start with the verb (the action) that the task performs. This will come in handy soon…


Key tasks necessary to achieve the goal are (not necessarily in sequence): “Receive ordered items”, “Request purchase of items”, “Review order request”, “Place order with supplier” and “Pay supplier”.

3. Determine the flow between tasks

Arrange the sticky notes on a large surface (e.g. A3 paper, office wall or table). Take the first task that needs to be performed and put it at the top. Take the next task and put it underneath the first task, and so on.

Play with the order of the tasks until you find the logical and simplest flow between tasks that achieves the goal.

Keep the taskflow simple by eliminating all non-essential tasks while still attaining the goal.


The flow between tasks is now “Request purchase of items”, “Review order request”, “Decline or approve order request” (refer to conditions), “Place order at supplier”, “Pay supplier” and “Receive ordered items”.


There are different patterns for the flow between tasks:

  • Linear: one follows the other,
  • Alternative: either one or the other task is performed,
  • Simultaneous: tasks perform at the same time,
  • Non-linear: previously completed tasks are reactivated by a task later-on.

You can make use of more than one of these patterns of flow in any taskflow.


The first task in a taskflow can be kicked-off by a person; an event in an external web-service; or a change of content (data-fields).

4. Add the role players

For each task, write down the role players that would be involved with that specific task. In the case of automated tasks, not every task necessarily will have a role player.


For human-facing tasks (tasks that involve humans), rather than writing down the role players’ names it is recommended that you write down their actual roles within the organization such as employee, manager, purchasing officer, executive management, HR, sales, finances, etc.

For human-facing tasks (tasks that involve humans), rather than writing down the role players’ names it is recommended that you write down their actual roles within the organization such as employee, manager, purchasing officer, executive management, HR, sales, finances, etc.


Now that you’ve added the roles, review the flow between tasks in the light of who will be doing what. Are there any tasks you can reposition that will benefit the flow? Are there consecutive tasks that the same role players will be working on? Can these tasks merge? Do you need to add any new tasks?

5. Add “connecting” tasks

In the case where consecutive tasks have different role players, the question arises: “how will the next task’s role player(s) know that they need to perform the task?”


In a Kotive taskflow app, all role players know the imminent task(s) they need to perform. This functionality is built-in to Kotive. A role player logs into her dashboard and sees an overview of her tasks. These are however passive notifications as she is required to login before being “told” what tasks she needs to do.

If you actively want to notify a role player, regardless if they login to the taskflow app or not, then you need to add “connecting” tasks into your taskflow.

What “connecting” task needs to be added to the taskflow as an in-between step that will actively notify the role player(s) in the next task? Examples of “connecting” tasks that actively notify role players are “Email”, “SMS”, “Slack” or “Hipchat”.

6. Build-out the individual tasks

Each task uses data to perform an action.

In the case of a form, data would be captured by completing the required fields. This data is then saved in data-fields, e.g. name, email address and quantity of items ordered.

In the case of automated tasks, examples of data-fields are:

  • Send an email: the data-fields would be To, Subject and Message.
  • Send a SMS: the data-fields would be Mobile number and Message.
  • Schedule a campaign in Mailchimp: the data-fields would be the API key, Scheduled time and Newsletter id.

The following template sentence could be used to help you identify each task’s data-fields:

“In order to {task to be performed}, as a {role player}, I need {list of data-fields}.”


In order to “Request purchase of items”,

as an employee I need:

  • the name of the person who asked for the purchase,
  • a description of each item,
  • the quantity needed of each item.

Now that you’ve built out the tasks, review the flow between tasks in the light of the flow of data. Is all the necessary data available to relevant tasks? Is there a data-field that needs to be included prior to the task being performed?


If you’re sending an email to confirm receipt of ordered items, then include a data-field in the “request purchase of items” task to capture the email address.

Review the flow of data between tasks. Is any data missing?

Now review the flow between tasks to see if any tasks can or should be repositioned. If any tasks are repositioned you will need to ensure that the necessary data is still available to all the tasks. Should a new task be included in order to get data that is missing from the taskflow?

7. Add preconditions to tasks

In Kotive’s context, a taskflow has a natural flow through tasks from top to bottom. (In general Business process management (BPM) works from left to right.) To kickoff the taskflow, the first task(s) is checked for any preconditions. If its preconditions are satisfied, the first task is initiated.

On successful completion of the first task, the process starts again from the top and determines the next task(s) in the flow by checking its preconditions. This process is repeated throughout the execution of the taskflow. Later on, we will explain the flexibility and power gained as a result of the recurring process of recalculating the flow from the top.

The role player(s) that you have previously added to each task is also its first precondition(s).


In our taskflow a manager needs to place the order at the supplier. The preconditions for the task “place order at supplier” is thus satisfied when the role IS manager.

The template sentence we will use for conditions is:

“The preconditions for this task are satisfied when {role} {comparison*} {value}…”

* The comparison can be one of the following: is, is not, greater than, less than and contains.

Go to each task and write down its precondition(s) for all its role player(s) using our template sentence. Some human-facing tasks may not have any role players. This is usually the case for publicly available online forms where people are not required to log in. None of the automated tasks have role players.

Next, you will determine if you need to specify any additional preconditions that are related to data-fields from within other tasks.


For the task “place order at supplier”, a precondition is that the order has been approved in the previous task (“review order”).

The preconditions for this task are satisfied when “Do you approve the order?” IS “Yes”.

The template sentence we will use for conditions can now be extended to:

{role or data-field} {comparison} {value}…”

Go to each task and write down its precondition(s) for its data-field(s). What conditions related to a data-field need to be satisfied before this task may be activated? There may be more than one or there might be none. Are there any data-fields missing in previous tasks that are required for this task’s preconditions?

You might now have tasks with more than one precondition. Do all these preconditions need to be satisfied? Or do only one of these preconditions need to be satisfied? Or are there combinations of these preconditions that need to be satisfied? Make use of AND and OR to group preconditions. If preconditions are multidimensional, use brackets () to group conditions, e.g. (X AND Y) OR (X AND A AND B).

Example #1

The preconditions for this task are satisfied when:

“Role” IS “Manager”


“Do you approve the order?” IS “Yes”

Example #2

The preconditions for this task are satisfied when:

( “Role” IS “Manager”


“Do you approve the order?” IS “Yes” )


( “Role” IS “Employee”


“Order value” LESS THAN “$10”


“Do you approve the order?” IS “Yes” )


When grouping multidimensional conditions use AND only inside the brackets () and OR outside brackets.

Now that you’ve specified all the preconditions you should be able to see how preconditions control the flow between tasks.

We mentioned earlier that after the completion of any task Kotive double-checks the preconditions of all the previous tasks. This repeated calculation makes non-linear and adaptive taskflows possible.


The initial order’s value was less than $10 therefor, according to our preconditions, the employee could approve their own order. However, when the value is confirmed in a later task (“Pay supplier”) it is more than $10. According to our preconditions, an order with a value of more than $10 needs to be approved by a manager. Thus, although the order was previously approved by the employee, the “Review order request” task is reopened and sent to the manager for approval before payment could proceed.The preconditions for this task (“Review order request”) are satisfied when:

( “Role” IS “Manager”


“Order value” GREATER THAN “$9.99” )


( “Role” IS “Employee”


“Order value” LESS THAN “$10” )

8. Review your original goal

Does the taskflow’s flow of tasks achieve its original goal? Are there any tasks which are not essential in achieving this goal? Is it possible to exclude these tasks from the taskflow in order to keep it simple? Should the taskflow be split into smaller taskflows?


You should now have a simple and logical taskflow, described on paper, that achieves its specific goal. The next step would be to design this taskflow electronically using Kotive.


We’d love to hear from you about the taskflows you design and some of the challenges you encounter. Please send us a message – we read every single one of them!

You might be interested in familiarizing yourself with other taskflow related concepts.