What is a Decision Activity?

A Decision Activity is a type of Interactive Activity that presents the end users with a list of business values (taken from the Process Instance) and prompts them to make a decision (i.e. what to do next) while suggesting the right answer based on past experience.

The Decision Activity is ideal in situations where a user needs to make a decision to route a process instance to one of multiple possible out-going transitions. By implementing the Decision Activity within a process model, you can assist your users in making a decision based on specific process variables.

For example, a Car insurance policy could be classified as low, medium or high risk depending on input variables like insured age, geographic area. This classification could be done with a Decision Activity, and over time the system will learn and suggest the most probable answer for each new policy.

The Process Execution Engine records end-user decisions and does statistical analysis in order to come up with suggestions for future decisions. This algorithm is based on Support Vector Machines (SVMs) methods.

Recorded decisions are evaluated and presented to end-users as a set of probability percentages. This allows users to make decisions based on the actions of previous users.

Note: In order for the Engine to provide a meaningful recommendation, the data for previous decisions must be consistent. Wide fluctuations in previous responses will cause the Engine's recommendations to be inconsistent.

Note: The Process Engine analyses the recorded decisions at periodic intervals as part of the Engine's Disposer service (by default, every two days). End users will not get any suggested probabilities until this service runs.

Decision Activities use standard component Fuego.Bis.DecisionProblem behind the scenes in order to record end-user decisions and present the suggested probabilities. For advanced use cases this component may be used directly from PBL, which allows you to feed the statistical algorithm and leverage the Process Engine analysis from any type of activity or BPM Object.

Using the Decision Activity

The following table outlines some of the considerations when using the Decision Activity within ALBPM Studio:

WorkSpace	The Decision activity is visible in WorkSpace, but only to the participant(s) assigned to the role where the Decision activity exists.
Roles	Decision activities must reside in user-defined roles. Note: If you add a new Decision activity and drop it in an automatic role, the BPM system will allow you to select an existing user-defined role or generate a new one (the Role dialog box populates.) The column-role is added to the design and the new Decision activity will automatically appear in the selected role.
Variables	Decision activities can access instance, and predefined variables.
Pre-conditions	An Incoming instance from another activity in the process with the necessary instance variables set. Decision activities can also be used as an exception handler.
Post-conditions	Instance moves to the next activity in the process via one of the outgoing transition lines.
Transitions	One or more incoming and outgoing transitions are required.
Tasks	The default behavior for Decision Activities consists in having one single Implementation or task. This greatly simplifies the understanding of Decision Activities. Furthermore, this simplifies the operation of WorkSpace, since executing an instance is ALWAYS executing its implementation. However, you can have Optional (or support) tasks that the participant may need to execute in some cases in order to help him do the required work (that is, executing the main task.) But if you look at optional tasks in this way, they make sense ONLY if you allow the user to execute them while executing the main task. To do so, these optional tasks must be read-only, meaning that they must not modify the instance data in order to avoid inconsistencies. The tasks have to be defined by the developer. The Decision activity has then a main task. Moreover, optional tasks can be added.
Business Process Methods	Decision activities can have one or more BP-Methods defined as tasks. Applications invoked from Decision activities are sent incoming parameters (set by BP-Method variables) and return outgoing parameters (which set BP-Method variables). Note: Human participants are unpredictable. If an end user begins a task in WorkSpace but does not complete it, a thread for that task remains open in the Engine. Too many open threads can cause poor server performance. To ensure that end users do not lock threads, use relay to in your BP-Method to immediately close threads and relay end user's response to another BP-Method task when the end user completes a task. See Controlling threads with relay to for further information.