Manual Review Decision Reasons

Overview

Auditors or reviewers from clients can now specify reason(s) why an application that went into a needs_review state was manually approved or declined. This feature can simplify an admin looking into an application later to figure out why the decision was taken at the point of manual review.

---

Prerequisites

• Access to the hv-central-config repository (gitlab.com/hvlabs/configurations/hv-central-config).

---

Purpose & use case

• Who is this for? SA/IE and Support Teams.
• When should this be used? When a client wants to get reasons for manually_approved or manually_declined status in the results API.

---

Step-by-step guide

Where should it be configured?

hv-central-config/platform-configurations/prod/appId/workflowId.json

What is the config structure?

{
    "dashboardManualReviewConfig": {
        "status": {
            "reasonsList": Array,
            "reasonType": Enum (single, multiple),
            "mandatory": Boolean,
            "allowCustomReason": Boolean
        }
    }
}

Breakdown of the config

1. status — The values should strictly only be manually_approved or manually_declined.
   1. reasonsList — Contains the list of pre-defined reasons to be displayed. Each reason should have a unique ID among that list and a text.
      • Default value: NA. Not adding this config would result in errors while updating the status.
   2. reasonType — Can either be single or multiple. This will help decide whether to allow a single or multiple reasons. If a reasonType of single is selected, only one reason would be stored in the DB and selecting multiple reasons would throw an error and the status update would not be done.
      • Default value: NA. Not adding this config would result in errors while updating the status.
   3. mandatory — When set to true, reviewer won't be allowed to move forward unless a reason is selected.
      • Default value: false.
   4. allowCustomReason — When set to true, the Other option is displayed on the pop-up, which the reviewer can then fill. The custom reason will be limited to a maximum length of 60 characters.
      • Default value: false.

How long until the changes are reflected?

The config added would take 15 minutes to come into effect.

How does this work?

Once the config comes into effect, the reviewers while approving or declining the application would see a pop-up where they would be able to view and select the reasons, which would then be sent to the backend as part of the payload.

The backend will perform validations as per the config for that status and would only continue to perform the status update if all the conditions are satisfied as per the config. These reasons will be stored in the audit portal DB as an array and in the analytics DB as a comma separated string.

Note

We only support storing reasons as a comma separated string in the analytics DB with a maximum length of 1024 characters. While configuring the reasons, please do ensure we do not add very long reasons and keep them as brief as possible while not impacting the readability and clarity of the reason.

How to consume these in the results API?

To consume these reasons in the results API, clients would need to pass a new flag:

• returnReviewDecisionReasons = yes
  • Default value: no.

This would start returning a new key reviewDecisionReasons in the results API response.

---

FAQs

Where can I see these reasons on the dashboard?

We currently do not support showing these on the dashboard.

Can I see these reasons on Metabase?

Yes, these reasons can be viewed on Metabase. They are stored in the analytics DB's platform-transactions table as a comma separated string with a maximum length of 1024 characters.