Page Comparison

Context:

This document covers below point:

• Workflow In general
• What is egov workflow-V1.1
• What is the diff b/w egov workflow-V1 and workflow-V1.1

Versions:

• V1 (Jan-2017  To Dec-2018)

• V1.1(Nov-2018 To Jan 2019)
• V1.2 (Apr-2019 To May-2019)
• V2 (Jun-2019 To Sept-2019)

Audience:

• Product Managers
• Developers
• Testers
• Co-creation partners
• Implementation Team
• Third Party(TP) integrators

What is

...

workflow?

...

Workflows are a series of steps that moves a process from one state to another state by actions performed by different kind of Actors - Humans, Machines, Time based events etc. to achieve a goal like onboarding an employee, or approve an application or grant a resource etc.

Why do we need Workflow ?:

User View:

• Manage worklist for user.
• Make people accountable.
• Control action task based on roles.

Development View:

• No need for recompiling.
• Rules kept as data.
• Easier rule editing.

Type of Workflow:

• Role based
• Department based
• Assignment Based
• Jurisdiction based
• Role + Jurisdiction based*

Objective V1.1:

• Role based workflow.
• Easy way of writing rule.
• File movement within workflow roles.

Key

...

Features:

Below are the feature list.

• Always allow anyone with a role in the workflow state machine to view the workflow instances and comment on it
• On the creation of workflow it will appear in the inbox of all employees that have roles that can perform any state transitioning actions in this state.
• Once an instance is marked to an individual employee it will appear only in that employees inbox although point 1 will still hold true and all others participating in the workflow can still search it and act if they have necessary action available to them
• If the instance is marked to a person who cannot perform any state transitioning action, they can still comment/upload and mark to anyone else.
• Overall SLA
• State level SLA
  
  

What is new in V1.1

Interaction Diagram:

Image Added

Feature list of  V1.2:

• Jurisdiction based
• Role + Jurisdiction based*
• Auto escalation.
• Machine actor.
• Simplify Integration for Service and Client(UI)
• Common inbox for all module.(Finance, Water)
• Generic Notification for wf
• Uploader for Rules & Config

Feature list of V2:

• New Version of wf API which will integrate with the Services so any module will no need to integrate with WF all will be take care by WF engine :)

How it works:

Workflow mainly depends on below section:

• Business Service

• State

• Action

• Role-Action

Business Service: Business service identifies each workflow configurations uniquely based Business(Module) and BusinessService(Business flow) .
Eg: In trade license module  Business:”TL” and “BusinessService: NewTLApplication“

State: State is sequence of steps in a workflow.
Eg: In Trade license Initiated,Applied,Paid,Canceled,Rejected,Approved are the states.

Action: State transition is depends on actions, based on action WF engine will decide the next possible State of task.
Eg: A action Apply can move a Trade license application from Initiated state to Applied state.

Role-Actions: Based on role action mapping in Workflow configuration Workflow engine will take the decision on acceptance of state-transition is possible or not

How to configure:

Workflow-V1.1 is highly configurable service, this section covers all the configuration.

Case 1: Simple three step workflow.

Image Added

Questions, Clarification & Suggestions:

1. If multiple clerks,
1. Once application initiated,  does it go to particular clerk’s inbox or it goes to everyone with role ‘clerk’?
   [Ghanshyam]: it will appear in all clerks inbox
   
   
2. Is there any provision to hold the application (in case of missing information) which sends notification to citizen?
1. If no, can we make such arrangement?
   [Ghanshyam]: As of now NO.
   
   
3. If there are multiple Jr. Engineers with same role
1. Can clerk mark it to particular Jr. engineer ?
   [Ghanshyam]: Yes, if  that role is configured for the WF
   
   
2. If yes, can other Jr. Engineers will be able to see the application and act on it?
   [Ghanshyam]: NO, other can’t see this, but whoever has marked JE that role employee can still see this and act on it.
   
   
3. If yes, Can we restrict other jr. engineers to take action on it or view it?
   [Ghanshyam]: Done in B point, Enjoy :)
   
   
4. Can Jr. Engineer send back application to clerk for clarification?
   [Ghanshyam]: Yes
   
   
5. Can sending application back to clerk, changes status of application?
   [Ghanshyam]: Yes
   
   
6. Can Jr. Engineer refer application for comments to the other person in the office?
1. If yes, to who all he can send the application for comments?
   1. All those who are part of ULB
   2. Those who are only registered in particular module
   3. Anything other this?

[Ghanshyam]: They can mark any employee whose role is configured for WF

1. Do others (to whom application is referred to) need to mark it back to Jr.  Engineer or they can mark anyone else?
   [Ghanshyam]: Yes
   
   
   1. Can JE takes action on application if it is being refer to others for comments?
      [Ghanshyam]: Yes
      
      
1. Can Clerk skip Jr. Engineer and send application to SDO directly and get it approve?
   [Ghanshyam]: Yes and No depends on configuration.
   
   
2. Can SDO pull application directly and mark it approve without being approved by clerk or Jr. Engineer?
   [Ghanshyam]: Yes and No depends on configuration.
   
   
3. What is reject application, does it terminate application temporary or permanent?
   [Ghanshyam]: Depends on configuration
   
4. Application once rejected, can citizen re-apply with same application or he has to start new (fresh) application?
   [Ghanshyam]: Depends on configuration