Business processes often include decision points where the workflow splits in three ways. This is a ‘go/no-go’ decision, with a third option to do additional work to make it clearer what the decision should be. By analogy within medicine, someone has to decide whether the case will live or die, or first requires diagnosis or treatment.
This article follows a series of articles aboutby introducing another: Triage.
The goal of the Triage pattern is to split a workflow according to whether success is certain, impossible or dependent on immediate action.
A complex or long-running business process often includes a go/no-go decision. For example, an impact assessment might conclude to proceed with a proposal, to abandon the proposal, or that there are issues that can be addressed.
A process often starts with triage, which you use to decide whether to accept each case. In a product support environment, for example, an incident report process starts with a decision whether to accept the case, or reject it because there is not enough information to identify the problem, say.
Use this pattern when a process milestone requires a decision whether to proceed with the case, and when you cannot always decide immediately. When you cannot decide, additional work might result in new information that makes the decision clear (diagnosis), or include corrective actions that can affect the decision one way or another (treatment).
This pattern can also add structure to a large complex process by creating a process boundary between sub-processes.
This pattern is based around an exclusive gateway that represents a decision with three possible outcomes. One outcome creates a corrective action user task, to address issues that prevent an immediate decision to proceed. In practice, the corrective action may expand to become a more complex sub-process.
Triage has a similar structure to an, but does not necessarily involve a separate process role, or use process data as the basis for the decision.
straight to your inbox