Since Dynamic Case Management is all about working together to get to the goal of the case, tasks is the tool to get a piece of work done. Tasks are there to change the case-dossier, so the system can derive its new (sub) goals and next possible steps. There are two different type of tasks in the Case-Engine: user-tasks, performed by an actual user, and automatic-tasks, where the system does some work (for example retrieving/sending data from another system, processing an incoming message event or sending a notification). Both are modelled slightly different.

Modelling a user-task

1. Determine (sub)goals

The task you want to add probably serves a purpose in getting closer to the goal. So it can make sense to start with modelling what you want to achieve with the task. Does the data I add to the case make a milestone true? Does it add to one of the subgoals of making a milestone true? This can be added in the Process domain module (in the implementation). For example to complete the milestone that the application is ready to be judged, I need to add a copy of my drivers license. The fact that the drivers license is present could be one of the subgoals, and can be added on the rule to check whether this milestone is true. 

2. Add task precondition

We should determine when our new task is relevant for a user to execute. Since we only want to bother users with necessary actions when it is needed to reaching the case goals, we should determine when it is relevant. This can also be added to the Process domain module (for example in a "Preconditie.<TaskName>" attribute). The actual rule for this added boolean can be modelled in the Process domain derivation module, since this module can access the case-dossier. In our example, the task of uploading a drivers license should be relevant when there is not yet a drivers license available in the case-dossier. When the document is available, then the precondition should be false, since we don't need to ask the user to upload the document anymore.

3. Add task implementation

In the task implementation module, a flow can be added where the actual work is done by the user. The complete dossier is retrieved at starting a task (make sure the user can only see what he needs and is authorised to see in the task implementation). When the task is completed, the new case-dossier state is sent to the Case-Engine to be processed. The dossier is retrieved and sent using the aggregate model of the case-dossier, so make sure this definition holds all information.

The task implementation should contain user-interaction, where the model is changed (in our example probably an upload container to upload you drivers license). The actual file would be uploaded to a document management system, but the dossier would hold the information that the drivers license has been added to the dossier. 

After the user-interaction, the flow can end with either a "Commit" or a "Rollback". 

Most likely is the commit, where the altered dossier is sent back to the Case-Engine, where the Case-Engine stores it, and determines what to do next.

The Rollback exit aborts the task for you, it does this without saving any information in the Case-Engine. Make sure you take this into account when creating the flow. In our example, the document could be stored in the document management system, but the dossier changes (the fact that the drivers license has been uploaded) will not be stored.

4. Add task definition in the process

Since the implementation side is finished, we can now turn to the process module. A task definition should be created using a sensible name and we should determine who may see and execute the task. This will most likely be done by someone with a specific role (or different roles). This could either be done by adding roles to the task definition, or adding an authorisation algorithm. Both achieve the same thing, but the authorisation algorithm is a little bit more flexible (you can group roles, and therefore change the set of roles for multiple tasks at once). In our example it should be someone with the role of "applicant", but maybe also someone who is handling the administration, for when the drivers license is emailed for example. There is no need to create exit event, we don't want the process to "flow" after this task, but we want the rules to determine what is next.

Add the new task in the right phase (process (sub)flow) as an ad-hoc task. Duplicate the precondition attribute in the process module, and add this attribute as condition on the ad-hoc task. Also, make sure it is repeatable, since the precondition should determine whether it should be relevant again or not.

5. Connect implementation and process using the configuration module

Now that the implementation has been created, and the process has been modified, we should connect the two models. In a configuration module we should extend the task mapping with our new task. By doing this, the Case-Engine knows which flow to start when the user tries to start the task.

Image Added

At the task mapping, the task from the process is connected to the flow implementation, there is no need to map events back to the process, since we have not defined any "flowing" events in the process. The last thing we should add is the right datamapping. This datamapping serves for the Case-Engine to update the process state with any new information after finishing the task. Usually there is one datamapping definition that is used to perform a datamapping after a task. 

The last step is to update the datamapping we've just selected in the task mapping. Since a precondition has been added, the process should know the value of this precondition after each finished task. Open the mapping, and map the precondition attribute from implementation to the process module.

Modelling an automatic-task

What is happening?

The models have been changed correctly, but the task is not visible in the list for the right user.

Make sure all steps above have been performed correctly. Notice that the dossier + rules derive the case-state, but the case-state itself is stored in the database. There are a few steps that can help debugging your issue:

1. make sure the case-dossier + rules lead to a precondition "true" Do you expect the task to be present in the current situation? Then opening the case, you can check the value of the precondition if the case should have been evaluated now (using the profile editor)
2. if the precondition is true, we can move on the the process. Check the process state in the DCM-Maintenance-APP for your case. There should be an attribute containing Precondition.<TaskName> set to TRUE. When there is no attribute, this means the attribute was not available during the last evaluation (last task execution form example).
3. Check the task-table in the DCM-Maintenance-APP. There should be a task set to "open" with the name modelled in the process. When there is not, something might have gone wrong adding your task to the process definition
4. When all of the above are available, it could be that the user is not authorised to perform the task, therefore not seeing the task.