start portlet menu bar

HCLSoftware: Fueling the Digital+ Economy

Display portlet menu
end portlet menu bar
Select Page

This is the second part of our four-part series covering how Workload Automation can mimic end-to-end processes on the insurance business side. (Here’s the link to the first part in the series, for your reference.)

Here, we examine the below process and try to mimic it using HCL Workload Automation.

A screenshot of a diagram Description automatically generated with low confidence

An insurance claim during the acceptance process undergoes completeness checks to make sure all documentation has been submitted as part of the claim. The results of the checks could lead to an email notification being sent to the contact or it could allow the process to go onto the next step.

The next step is if the claim needs to be escalated. The escalation requirement could result in either the escalation sent to a portal for further review and approval.

In case escalation is not needed for the claim case, it would undergo acceptance check and result in the claim set to pending in case some further clarifications are needed or result in claim being accepted and registered into the system.

The data pertaining to the claim form and documentation is already present stored in a Mongo DB and the same is accessed via Docusumo APIs exposed in the foreground, one could also substitute this with an equivalent product like IBM Discovery API, Google Cloud Vision API, etc.

Completeness check of insurance form data:

The completeness check of the insurance form data is performed via HWA job realized as a RESTFUL GET job which would leverage Docusumo APIs to perform a RESTFUL GET operation to get the data from a Mongo DB (where all data resides):

The joblog of this job would be as follows:

A screenshot of a computer Description automatically generated

This job would also have conditional dependencies to determine if the data is complete:

So, this looks for the keyword “N/A” in the joblog and decides whether the data is complete or if there are missing fields in the scan done earlier from Docusumo:

A picture containing text, screenshot, font Description automatically generated

Completeness Check of Insurance Attachment Data:

The completeness check of insurance attachment data is done via a by making a RESTFUL GET call via an HWA Job into the same Mongo DB serviced via an Internal API running in the background:

The completeness check of documentation data is again validated with conditional dependencies defined at the job level where the string “N/A” in the joblog indicates this data was not available in the scan or is missing, this would result in the condition “NOTCOMPLETE” getting satisfied:

If the “NOTCOMPLETE” condition is satisfied, this results in a mailing job to send notification to the customer via email to intimate him about the missing data.

Email notification job for completeness check of image data (attachment data):

The mail notification job sends a notification out that the documentation is not complete:


This is realized as Unix Job to check if a claim escalation is needed in this case, so the script called evaluates if the value returned is beyond a particular value:

There would be conditional dependencies defined where every Return Code is mapped to “REQ”, “NOT_REQ”. So, depending on the Return Code 5 or 0, the corresponding conditions are passed that is Required and Not Required.

In case escalation is required, SEND_CLAIM_ESCALATION_PORTAL job is called to do a RESTFUL POST job into the Portal such that the Claim is escalated for further approvals to higher Management in case the amount is beyond a particular value.


The MAKE_ACCEPTANCE_DECISION job would run either a AWS Lambda Function or Google Cloud Functions to run in a serverless fashion on AWS or GCP where the evaluation is performed using Analytics in the background or in the form of a Google Big Query job or Azure Data Bricks job to check if the Claim can be accepted based on historical data captured from previous trends or a Custom Function written by the Insurance Company or if it is to be put to “pending” or it can be “Not Accepted”.

A screenshot of a computer Description automatically generated with low confidence

There would be conditional dependencies defined where every Return Code is mapped to either “ACCEPT”, “NOT_ACCEPTED” and “PENDING”. So, depending on the Return Code 127, 37 or 0, the corresponding conditions are passed.

A picture containing text, line, diagram, font Description automatically generated


This job sets the claim to pending in the Mongo DB, so that the claim could further evaluated manually for further checks from the insurance company:

A screenshot of a computer Description automatically generated with medium confidence

In case “ACCEPT” condition is passed, the claim is accepted through “RESGITER CLAIM” job & a mail notification is sent out via Mailing job to intimate the registration of the claim is completed successfully.

Whole Flow at HWA Side:

A picture containing text, font, line, diagram Description automatically generated


Comment wrap
Automation | March 20, 2024
Optimizing Cloud Processes: Unleashing the Power of HCL Workload Automation with AWS Step Functions
Automate complex workflows with AWS step functions and HCL Workload Automation. Learn how to connect and use the AWS Step Functions Plug-in for efficient workload orchestration.
Automation | March 13, 2024
Enhancing Automation: HCL Workload Automation and AWS Step Functions
Unlock powerful automation: HCL Workload Automation and AWS Step Functions join forces. Expand integration, manage hybrid clouds, optimize costs and more!
Automation | February 23, 2024
Demystifying OpenID Connect, OAuth 2, and JWTs on HWA
Integrate IBM/HCL Workload Automation with Okta, Auth0, Ping, Microsoft Entra ID, or SiteMinder via OpenID Connect for streamlined identity management.