This content applies solely to Connected Onboarding, which must be purchased separately from the Appian base platform. This content was written for Appian 23.3 and may not reflect the interfaces or functionality of other Appian versions. |
Appian Connected Onboarding includes field validations in order to prevent users from entering bad data during the onboarding process.
This has several important benefits:
This document describes the underlying validation structure for the Create Onboarding form. It also explains how to add to and edit the default validations.
There are two types of validation messages that the user sees on the Create Onboarding form:
Field validation: Appears under certain fields after invalid data is entered in the field.
Product validations: Appear on the Add Products page of the create onboarding wizard. They display as:
An indicator next to the product name with an issue. As soon as the user fixes all of the errors for that product, the indicator disappears.
A message on the bottom of the page after the next button is clicked. This tells the user which product the error is in and prevents the form from being submitted. As soon as the user fixes all of the errors for that product, the validation message disappears.
The types of default validations that are set up for the Create Onboarding form are:
For every field that allows free text entry, there is a maximum length validation. If the user enters data that exceeds the maximum length allowed by the field, it will be outlined in red and the user sees a message that states the maximum amount of characters.
By default, there are several required fields that must be filled out before submitting the form. These fields are denoted with an asterisk (*).
Out of the box, the following fields are always required:
The following fields are only required if the parent field is added:
Connected Onboarding uses the standard Appian restrictions on fields to validate invalid data types. The user sees a message on fields where an improper type has been entered.
For example, if the field is an integer data type, entering text will cause a validation error.
To change the default validations for product fields, you will need to update two places:
Most of the length validations on the field are set by constants.
The constants for the length validations are:
AS_IO_CO_ENUM_TEXT_LENGTH_SHORT
: 20 characters for text fieldsAS_IO_CO_ENUM_TEXT_LENGTH_MEDIUM
: 50 characters for text fieldsAS_IO_CO_ENUM_TEXT_LENGTH_LONG
: 255 characters for text fieldsAS_IO_CO_ENUM_PARAGRAPH_LENGTH_SHORT
: 255 characters for paragraph fieldsAS_IO_CO_ENUM_PARAGRAPH_LENGTH_MEDIUM
: 1000 characters for paragraph fieldsAS_IO_CO_ENUM_PARAGRAPH_LENGTH_LONG
: 4000 characters for paragraph fieldsThese constants are used in many places, so their values should not be changed. If you want to use a different max field length than those here for any field, you can create a new constant and use it to control the field length more specifically.
Use a naming convention such as AS_IO_INT_<CDT NAME>_<FIELD NAME>_LENGTH
for setting a specific field length to make identification easy.
When increasing the maximum length validation on a field, you also need to update the length of the field in the database to accommodate for the longest possible string of text.
The first step to changing a validation is updating the field that requires the change.
To change the validation on a field:
maxLength
parameter as described above
validations
parameter.Once you have changed the field level validations above, you will need to mirror any change in the corresponding form level validations. This paradigm is used because some fields may be hidden during the course of a user’s interaction with the form. For example, when the user switches which product they are updating.
If a field level validation is added and the corresponding form level validation is not automatically included, end users will not be warned that their data is incorrect. Similarly, if a field level validation is removed without the corresponding form level validation being removed, the user will be unable to move forward because the form level validation message will still appear even though the field level validation is not showing.
Any logic that is added to the field validation will need to be mirrored in the corresponding isValid
metadata rule for the field. The logic found in the isValid
rule should be made to return false when the validation is triggered, and true when it is not. Null should be returned if no product is passed, to avoid unnecessary computation, which is especially relevant if a query or more complex logic is involved in the validation.
The fields for Accounts are found in the rule AS_IO_CPS_OnboardingRequestProducts_AccountsSection
. By default, the account number and account name have length validations of AS_CO_ENUM_TEXT_LENGTH_MEDIUM
and must be unique.
This example shows how to add another validation to Account, which would require the account number needed to start with the letter A
.
AS_IO_CPS_OnboardingRequestProducts_AccountsSection
and find where the where the account number validations are found (line 176 in the rule as shipped).Add in the logic for the validation requirement.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
validations: {
if(
rule!AS_CO_UT_checkIfDuplicateExistsInArrayByIndex(
array: ri!product.accounts.accountNumber,
index: fv!index
),
rule!AS_CO_I18N_UT_displayLabel(
i18nData: ri!i18nData,
bundleKey: "ProductField.vld_DuplicateAccountNumber"
),
null
! ),
! if(
! index(code(fv!item.accountNumber), 1, null) <> code("A")[1],
! rule!AS_CO_I18N_UT_displayLabel(
! i18nData: ri!i18nData,
! bundleKey: "ProductField.vld_AccountNameMustStartWithA"
! ),
! null
! )
}
AS_IO_REF_PRODUCT_FIELDS_ACCOUNTS
.Add the same logic to ensure that even if the field is hidden, the validation is triggered.
1
2
3
4
5
6
7
8
9
10
11
12
13
isValid: if(
rule!AS_CO_UT_isBlank(ri!product),
null,
and(
a!forEach(
items: ri!product.accounts,
! expression: and(
! len(fv!item.name) < cons!AS_CO_ENUM_TEXT_LENGTH_MEDIUM,
! index(code(fv!item.name), 1, null) = code(“A”)[1]
! )
)
)
)
Modifying Validations