Workflow determines what happens to an issue when it is created, the states that it must subsequently pass through and the tasks that must be completed for each state.
Ketura makes it possible to define sophisticated workflows to guide issues from creation to completion. However, it’s possible to use Ketura productively without explicitly defining any workflow at all.
Ketura can automatically create default workflow for new projects, so that new issues relating to the project are added automatically to the project’s ‘Review New Issues’ milestone.
As you become familiar with the product and how best to use it effectively, you can start to define and refine workflows that are appropriate for your work and organization.
The state of an issue simply describes how far along the workflow the issue has progressed. See Ketura Tour Step 2: Issues for more information about states.
Any number of states can be configured, although Ketura comes with a useful starter set (‘New’, ‘Pending Resolution’, ‘In Progress’, ‘Rejected’, ‘Resolved’, ‘Duplicate’, etc).
When an issue is created, it is set to a state indicating that it is new and has not yet been processed. Unless renamed, this state is called ‘New’.
It is possible to restrict the allowable transitions between issues. For example, it might be possible to change a state from ‘New’ to ‘Awaiting Scheduling’ or possibly a ‘Rejected’ state, but not directly to any other. Then, from ‘Awaiting Scheduling’, the only allowed transition might be to state ‘Pending Resolution’. By specifying the allowable state transitions in this way, particular workflows can be enforced.
Consider a simplified example of a company in which a customer care representative screens complaints. If the representative decides that a particular complaint relates to a defect in a particular product created by the company, he or she might assign the issue to the manager of the topic involved. That manager might then schedule the issue to be rectified by a particular individual in the project plan relating to the ongoing maintenance of the product. The team member would, eventually, start work on the issue, fix it, then mark it as resolved. The requirement here is that the issue pass through a pre-determined set of states. In this case, they might be ‘New’, ‘Awaiting scheduling’, ‘Pending resolution’, ‘In progress’ and, finally, ‘Resolved’.
Workflow can be used to define the tasks that must be completed for an issue to be resolved. This is done by specifying a set of tasks (refer back to Ketura Tour Step 3: Tasks) that should be added to the issue when it enters a particular state. Each task in the task set can be assigned to a particular person by default, but can be reassigned if desired. Tasks may also manually be added to or removed from an individual issue, as required.
The desired workflow for an issue will typically depend on what the issue is about. For example, what should happen to an issue about a company’s website will be different from what happens to an issue relating to a company’s internal procedures. In Ketura, a distinct workflow can therefore be defined for each issue topic. All the issues about a particular issue topic therefore have the same workflow.
Ketura can automatically add new issues to a particular project milestone, depending on each new issue’s topic. This can be used to ensure that someone has the responsibility of reviewing every new issue. For example, new issues for a given topic might be added to a related project milestone ‘Review New Issues’. The workflow for that topic might also state that a task set containing a single task ‘Decide what to do with the issue’ is added to that topic’s issues when they enter the ‘New’ state (that is, when they are created). That task’s assignee would automatically then have the responsibility for reviewing each new issue created for the topic.