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

This component is directly integrated with the ApplicationDetailsContent component that renders all the relevant data in view screens. WorkflowTimeline component is called in this component like this:

It expects a few props:

• BusinessService -> Name of the businessService 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 state then it will show an extra checkpoint at the top with statusAttribute as status to show pending states checkpoint. If the current state is terminated state then it will not show pending states.

Refer to the below snapshots, notice they both have 4 checkpoints. Approved refers to terminate 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 businessService from workflow configuration

• forcedActionPrefix -> for localization

• applicationNo -> Idgen generated application number

• tenantId

• applicationDetails -> same data returned from hook used on 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 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 popup that renders whenever the user clicks on a specific action. This popup is fully configurable through this configuration file Popup Config. Popup configs are defined in this configuration file which are organised as per the businessService of the workflow configuration. Refer to the configMap object in this file for more details.