Task based update - technical details

The proposed solution is based on Workflow: Task based update of entities.

We need to provide a generic way to handle changes in entities. Tasks should be automatically created through signals by the application backend and accessible from one place on the UI. All modules should be able to make contributions to the main Tasks Page.

There will be 2 types of Users interacting with the tasks:

• Task Triage is responsible for managing the users that can work on certain tasks. It is an actual role with the right authorities.

• Task Executor is the person responsible for executing the task. They’re defined as a group of users called Task Group.

Proposed flow of tasks:

Open

In this scenario, Tasks are defined in the backend and triggered by specific actions.

User Interface

We will need one new view that will handle functionality for both Task Triage and Task Executor.

For Task Executor:

For Task Triage:

Source defines an entity Requesting the change.

Type represents what kind of task the user has. Different types of tasks can have other BusinessActions.

Entity informs about what object is being changed (specific individual, beneficiary, etc.)

Preview is an action allowing the user to check how a task affects the state. In the case of a beneficiary update, it could display a modal explaining what changes will be applied.

Assignee is a group of users that are authorized to complete the task. Task executioner groups should have assigned approval policies that determine when a given task is considered finished by the group. It could be: at least one approval, approval threshold, all members approval.

BusinessStatus allows the user to take proper action on a given task. The possible approach for this field is different for different task groups. It could, for instance, Approve/Reject changes in an update request or set a new amount for a policy adjustment request. It could be a three-dot menu, a dropdown, or text inputs.

Status represents the current state of the task. According to the FHIR standard and our current needs, we should have the following states:

• Received - when new tasks appear in the system

• Accepted - when task is assigned to the executioner

• Completed - when changes were approved by executioner

• Failed - when changes were not approved

Open

This view shows all existing tasks in the openIMIS application. It is a low level placeholder to which other modules can contribute. In the graphic below, Benefit Plan Tasks is a contribution from SocialProtection module. Most of the entities are similar to those in the “My Tasks” view.

If a given user is a Triage but not an Executor of a task, BusinessStatus is blocked.

If a given user is an Executor but not Triage of a task, then the Assignee is blocked.

Entities

Stories

1. Story 1 - Task Creation: As a system, when a certain event is triggered, I want to create a new task so that the corresponding workflow can be started.

2. Story 2 - Task Management: As a Task Triage, I want to have access to all tasks I’m eligible to manage (e.g. BenefitPlanTasks).

3. Story 3 - Task Assignment: As a Task Triage, I want to assign specific tasks to previously defined user groups.

   1. ALT: As a system, when a new task is created, I want to assign it to a user or group based on predefined rules so that the task can be executed by the appropriate party.

4. Story 3 - Task Execution: As a Task Executor, I want to see only the relevant information for the entity page and be able to validate information as necessary so that I can complete the task without confusion or errors.

5. Story 4 - Task Completion: As a Task Executor, when I finish a task, I want to update its status so that the system can determine the next steps in the workflow.

6. Story 5 - Workflow Progression: As a system, when a task is completed, I want to determine the next steps based on the current workflow implementation and status so that the workflow can progress smoothly.

7. Story 6 - Group Management: As a Task Triage, I want to create/update/delete group of task executioners that can be assigned to specific tasks.

Use Cases

Use Case 1 - Task Creation:

Actor: System (Triggered By Event or Mutation)

Trigger: Action in the system. (e.g. User Uploading Data / New Request in API)

Preconditions:

1. TaskCreation action is listening to an event.

Main Flow:

1. The user performs certain action in the system.

2. The event attached to this action is triggered

3. TaskReceiver binded to the event gets new action

4. New Task object is created with status RECEIVED

5. Task is saved in storage

6. New Task appears under “My Tasks” view for certain Task Triages

Extensions:

N/A

Postconditions:

1. The task has been created.

2. Task Triage can assign the task to group.

Use Case 2 - Task Assignment:

Actor: Task Triage (User)

Trigger: New task was added to the system

Preconditions:

1. Task Triage has access to manage certain tasks.

Main Flow:

1. Task Triage goes to the “Tasks” view

2. Under specific extension point tasks (like Benefit Plan) Task Triage selects a group of users that will work on given task from the list of groups.

3. Status of the task changes to ACCEPTED

Postconditions

1. Group of executioners that had task assigned to them can see new task under “My Tasks” view

Extensions:

Tasks could be automatically assigned to the groups based on rules

1. New task is saved in the system.

2. TaskCreate event is triggered

3. Based on criteria, the task is assigned to one group

Alternative Flow - Task Rejected :

1. Task Triage goes to the “Tasks” view

2. Task Triage doesn’t approve the task and changes status to REJECTED

Use Case 3 - Task Execution:

Actor: Task Executor (User)

Trigger: Task was assigned to the group of users

Preconditions:

1. Task Executor user belongs to the group that has task assigned to them

Main Flow:

1. Task Executioner goes to “My Tasks” view.

2. Task Executioner reviews the task.

3. Task Executioner open “Preview” that shows them edited entity.

4. Task Executioner Accepts the changes.

5. Task status is changed to COMPLETED

6. Trigger for specific status completion is invoked (“completeAction” from Task entity)

Postconditions:

1. The task is signed off by User

2. The task is marked as COMPLETED

3. “completeAction” event is triggered with “Data” stored in Task as an input

Extensions:

3a. Task Executioner could have possibility to edit information in the “Preview” tab. This would become useful in the long term as Tasks wouldn’t only reefer to actions outside the flow, but be actual part of it. Implementation of action would change from tasks to task. For instance in Claim workflow user could have edit options on certain fields (but not all of them, it’d be specified by task type and contributed UI).

Alternative Flow - Other Group Policy :

4. If user’s approval was not enough to mark the task as completed then further actions are awaited for

5. Status remains the same

Alternative Flow 2 - Task Failed:

4. User doesn’t approve the changes and Rejects them instead of accepting

5. Task status is changed to failed

6. Task event is not triggered

Use Case 4 - Group Creation:

Actor: Task Triage (User)

Trigger: N/A

Preconditions:

1. Task Triage has access to create Task Executioner Groups

Main Flow:

1. Task Triage goes to Users → Task Executioner Groups (added as extension)

2. Task Triage select users that will be in scope of the Group

3. Task Triage select GroupPolicy from dropdown

4. New Task Group is created

Postconditions:

1. Created group can be assigned to the tasks by the Test Triage

Extensions:

2a. We might want to add restrictions based on the user roles / rights / locations in terms of creating groups to keep them coherent?