> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/local-governance/v2.7/platform/configure-digit/configuring-digit-services/configuring-workflows/configuring-workflow-for-an-entity.md). # Configuring Workflows For An Entity ## Overview Workflow is defined as a sequence of tasks that has to be performed on an application/Entity to process it. The *egov-workflow-v2* is a workflow engine which helps in performing these operations seamlessly using a predefined configuration. We will discuss how to create this configuration for a new product in this document. ## Pre-requisites Before you proceed with the configuration, make sure the following pre-requisites are met - * *egov-workflow-v2 service is up and running* * Role-Action mapping is added for business Service APIs ## Key Functionalities * Create and modify workflow configuration according to the product requirements * Configure State level as well BusinessService level SLA to efficiently track the progress of the application * Control access to perform actions through configuration | Attribute Name | Description | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | tenantId | The tenantId (ULB code) for which the workflow configuration is defined | | businessService | The name of the workflow | | business | The name of the module which uses this workflow configuration | | businessServiceSla | The overall SLA to process the application (*in milliseconds*) | | state | Name of the state | | applicationStatus | Status of the application when in the given state | | docUploadRequired | Boolean flag representing if document are required to enter the state | | isStartState | Boolean flag representing if the state can be used as starting state in workflow | | isTerminateState | Boolean flag representing if the state is the leaf node or end state in the workflow configuration. *(No Actions can be taken on states with this flag as true)* | | isStateUpdatable | Boolean flag representing whether data can be updated in the application when taking action on the state | | currentState | The current state on which action can be performed | | nextState | The resultant state after action is performed | | roles | A list containing the roles which can perform the actions | | auditDetails | Contains fields to audit edits on the data. *(createdTime, createdBy,lastModifiedTIme,lastModifiedby)* | ## Deployment Details 1. Deploy the latest version of egov-workflow-v2 service 2. Add businessService persister yaml path in persister configuration 3. Add Role-Action mapping for BusinessService APIs 4. Overwrite the egov.wf.statelevel flag ( *true* for state level and *false* for tenant level) ## Configuration Details The Workflow configuration has 3 levels of hierarchy:\ a. BusinessService\ b. State\ c. Action\ The top-level object is BusinessService, it contains fields describing the workflow and a list of States that are part of the workflow. The businessService can be defined at the tenant level like pb.amritsar or at the state level like pb. All objects maintain an audit sub-object which keeps track of who is creating and updating and the time of it. ``` { "tenantId": "pb.amritsar", "businessService": "PGR", "business": "pgr-services", "businessServiceSla": 432000000, "states": [...] } ``` Each State object is a valid status for the application. The State object contains information about the state and what actions can be performed on it. ``` { "sla": 36000000, "state": "PENDINGFORASSIGNMENT", "applicationStatus": "PENDINGFORASSIGNMENT", "docUploadRequired": false, "isStartState": false, "isTerminateState": false, "isStateUpdatable": false, "actions": [...] } ``` The action object is the last object in the hierarchy, it defines the name of the action and the roles that can perform the action. ``` { "action": "ASSIGN", "roles": [ "GRO", "DGRO" ], "nextState": "PENDINGATLME", } ``` The workflow should always start from the null state as the service treats new applications as having null as the initial state. eg: ``` { "sla": null, "state": null, "applicationStatus": null, "docUploadRequired": false, "isStartState": true, "isTerminateState": false, "isStateUpdatable": true, "actions": [ { "action": "APPLY", "nextState": "APPLIED", "roles": [ "CITIZEN", "CSR" ] } ] } ``` In the action object whatever nextState is defined, the application will be sent to that state. It can be to another forward state or even some backward state from where the application has already passed\ *(generally, such actions are named SENDBACK)* SENDBACKTOCITIZEN is a special keyword for an action name. This action sends back the application to the citizen’s inbox for him to take action. A new State should be created on which Citizens can take action and should be the nextState of this action. While calling this action from the module *assignees* should be enriched by the module with the UUIDs of the owners of the application ## Integration Details For integration-related steps please refer to the document [**Setting Up Workflows**](/local-governance/v2.7/platform/configure-digit/configuring-digit-services/configuring-workflows/setting-up-workflow.md). ## Reference Docs #### Doc Links | Description | Link | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workflow Service Documentation | | | Setting Up Workflows | [ttps://digit-discuss.atlassian.net/wiki/spaces/DD/pages/644546619/Setting+Up+Workflows](https://digit-discuss.atlassian.net/wiki/spaces/DD/pages/644546619/Setting+Up+Workflows) | #### API List | Description | Link | | ----------- | ------------------------------------------------------------- | | *\_create* | | | *\_update* | | | *\_search* | | *(Note: All the APIs are in the same postman collection therefore the same link is added in each row)* [![Creative Commons License](https://i.creativecommons.org/l/by/4.0/80x15.png)​](http://creativecommons.org/licenses/by/4.0/)All content on this page by [eGov Foundation](https://egov.org.in/) is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.digit.org/local-governance/v2.7/platform/configure-digit/configuring-digit-services/configuring-workflows/configuring-workflow-for-an-entity.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.