The Q2 Gro application software can refer an applicant based on custom values that can include some unstructured variables and any of the default attributes included below.
For primary applicants
-
city
-
state
-
postal
-
country
-
workCity
-
workState
-
workPostal
-
idType
-
birthDate
-
idState
-
occupancyDuration
For joint applicants
-
birthDateApp2
-
idTypeApp2
-
workCityApp2
-
workStateApp2
-
workPostalApp2
-
occupancyDurationApp2
You can configure additional attributes to use as decision criteria. You can include any information using unstructured variables, but must ensure that the Applicant property key and applicant attribute exactly match.
Note
You can't use JSON objects in unstructured variables used for this purpose.
To establish decision criteria, you must make several configuration changes in the server.workflow.service.custom.decisioningWorkflow Type ID. In the example shown below, decisionOnStateAttr is used as the default for your decision criteria or "className" variable. However, you can choose any custom name for this variable. Copy the following configuration into the decisioningWorkflow section of your configuration to make desired changes.
"decisioningWorkflow": [
{
"workflowStep": "decisionOnStateAttr|decisionOnApplicantAttr",
"criteria": {
"authenticated": true,
"existingCustomer": true,
"products": [
"all"
]
}
},
Within the configuration, the "workflowStep" variable in the server.workflow.service.custom.decisioningWorkflowSettings Type ID sets accepted decision criteria, with any non-allowed decision criteria resulting in an automatic referral.
Caution
"workflowStep" and "className" variables must be exact matching values. For example, if your "workflowStep" variable is decisionOnApplicationStates, your "className" variable must also be decisionOnApplicationStates. See below for more information.
{
"decisionOnStateAttr": {
"className": "decisionOnApplicationState",
"settings": {
"decisionStepName": "internalCommentsDesOnAppStepName",
"continueCriteria": {
"state": ["MI", "NY"]
}
},
"productTypes": [
"all"
]
}
}
In the below example, the configuration allows the ZIP code 40476 and 30303 as acceptable values and refers applications containing any other ZIP code. For a ZIP code that is serviced, add the ZIP code to the continueCriteria property as shown below. You can also set a certain ZIP code to be automatically referred by using the stopCriteria property instead of the continueCriteria.
Note
stopCriteria and continueCriteria cannot be used in the same rule.
{
"decisionOnApplicationZipCodes": {
"className": "decisionOnApplicationState",
"settings": {
"decisionStepName": "internalCommentsDecisionZipCodeStepName",
"continueCriteria": {
"postal": ["30303", "40476"]
}
},
"productTypes": ["all"]
}
}
After adding ZIP code decisioning into the configuration, update the server.custom.messages.en and client.custom.messages.en configurations, as follows.
Caution
Configuration below applies to elements of the user interface. By making configuration changes, you are directly modifying what is displayed.
You can make changes to the internal comments section of the application user interface by applying configuration changes explained in the below examples.
Add the following message key and value to the server.custom.messages.en Type ID.
"internalCommentsDecisionZipCodeStepName": "Application Zip Code",
Add the following message key and value to the client.custom.messages.en Type ID. The example configuration below would result in naming the new dropdown in the Actions menu to "Decision on Application Zip Code".
"decisionOnApplicationZipCodes": "Decision on Application Zip Code",
There are verification steps in the application decisioning process to help prevent potentially fraudulent email address information in the application process.
You can enable this feature by updating your configuration, as shown in the following process:
Note
Both configurations in the example below must be included to enable fraudulent applicant verification.
-
To verify that the applicant's email address doesn't contain more than three periods, add the following configuration to the
server.workflow.service.custom.decisioningWorkflowType ID:{ "stopStrategy": "immediate", "defaultDecision": "continue", "decisioningWorkflow": [ { "workflowStep": "advancedDecisionOnApplicationAttribute", "criteria": { "authenticated": false, "products": [ "all" ] } } ] } -
To verify that the applicant's email address isn't blacklisted, add the following configuration to the
server.workflow.service.custom.decisioningWorkflowSettingsType ID:{ "advancedDecisionOnApplicationAttribute": { "className": "advancedDecisionOnApplicationAttribute", "settings": { "decisionStepName": "internalCommentsDesOnAppStepName", "matchAll": false, "operations": [ { "operator": "contains|partial", "property": "email", "value": "acme.com,zzz.com" }, { "operator": "function", "property": "email", "value": "propertyValue.split('@')[0].split('').countBy{it}.get('.')>=3" } ] } } }
After the above changes have been made, test the application. You can test an application by opening an application in the Gro Admin Portal, and selecting Run Decision on Application Zip Code in the Actions dropdown menu.
If ZIP code decisioning has been properly configured with a ZIP that passes validation, the internal comments should look like this:
If ZIP code decisioning has been properly configured with a ZIP that fails validation, the internal comments should look like this:
To verify the state provided with an address, edit the server.workflow.service.custom.decisioningWorkflow Type ID as follows.
{
"workflowStep": "decisionOnApplicationStates",
"unauthenticated": true,
"authenticated": true
}
In the following example, the state is used in the decisioning criteria to allow TX and CA in the state dropdown within the server.workflow.service.custom.decisioningWorkflowSettings,but refers the user using stopCriteria.
{
"decisionOnApplicationStates": {
"className": "decisionOnApplicationAttribute",
"settings": {
"decisionStepName": "internalCommentsDecisionStateStepName",
"stopCriteria": {
"state": ["TX","CA"]
}
},
"productTypes": ["all"]
}
}
Add the following message key and message to server.custom.messages.en.
"internalCommentsDecisionStateStepName": "Application State Verification",
Add the following message key and message to client.custom.messages.en.
"decisionOnApplicationStates": "Decisioning on Application State",
Test the application by opening an application and selecting Run Decisioning on Application State in the Actions dropdown.
If decisioning by state has been properly configured with a state that passes validation, the internal comments will look like this:
If decisioning by state has been properly configured with a state that fails validation, the internal comments should look like this: