Workflow Component

Overview

There are two common components for workflow-related actions and timeline management.

• WorkflowActions - WorkflowActions

• WorkflowTimeline - WorkflowTimeline

Both of these components are available on each View Screen. The WorkflowTimeline component is responsible for presenting the workflow history at the bottom of the View Screen. Similarly, the WorkflowActions component renders an action bar at the bottom of the view screens, showcasing pertinent actions based on the logged-in user's role and workflow configuration.

Workflow Timeline

The WorkflowTimeline component integrates directly with the ApplicationDetailsContent, responsible for displaying all relevant data in the view screens. It calls the WorkflowTimeline component in the following manner:

It expects a few props:

• BusinessService -> Name of the business service from workflow configuration

• applicationNo -> Idgen generated application number

• tenantId

• timelineStatusPrefix -> prefix used in localisation of every checkpoint in timeline

• statusAttribute -> here we can pass the attribute(either status/state) that is the key in the workflow process instance response, whichever we want to show in the checkpoint.

This component internally calls the workflow APIs to fetch the process instance of the application and renders the history accordingly. It also makes a check for the current state of the application. If the current state is not terminated, then it will show an extra checkpoint at the top with statusAttribute as status to show the pending states checkpoint. If the current state is terminated, then it will not show pending states.

Refer to the snapshots below, notice that they both have 4 checkpoints. Approved refers to the terminated state.

Workflow Actions

This component is rendered on every View component separately to render the action bar with relevant actions.

\

Sample code snapshot:

It expects a few props:

• BusinessService -> Name of the business service from workflow configuration

• forcedActionPrefix -> for localisation

• applicationNo -> Idgen generated application number

• tenantId

• applicationDetails -> same data returned from the hook used on the view screen

• Url -> update API url to hit

• setStateChanged -> when update is successful, this is called. Hence, search APIs will be called again, and workflow history and workflow actions will be updated without a screen refresh

• moduleCode

• editApplicationNumber -> Used in case of edit/modify action

This component internally calls the update APIs and shows a relevant toast on success/failure or a response screen in case of edit action.

A significant part of this component is another component called the WorkflowPopup. This is the pop-up that renders whenever the user clicks on a specific action. This pop-up is fully configurable through the configuration file Popup Config. Popup configs are defined in this configuration file, which are organised as per the business service of the workflow configuration. Refer to the configMap object in this file for more details.