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. |
Use this page as a way to get familiar with the Connected Onboarding before getting started on customizing or configuring the solution. This page outlines and explains the patterns developed by the Appian Solutions developers to make it easy to navigate and understand the solution when you are making changes. You can find additional examples that show how to customize and modify your solution documented in the Modifying section.
Connected Onboarding has three main sites, each targeted at a different user group.
Connected Onboarding uses Appian records and record relationships to power the Onboarding processes. The two main records included in the Connected Onboarding solution are: Customer and Onboarding records.
Customer records are the highest level of records in the solution and can have many Onboarding events. Any piece of runtime data is going to be related to either of these two records.
Specific prefixes are used for consistency and to give a high level understanding of the object or database table. Prefixes are used to indicate where the object is used and what the object is used for.
AS
is the prefix for all objects and database tables that are created and included in the Connected Onboarding solution. This will help differentiate objects that were shipped as part of the solution. It is recommended that for new created custom objects that implementation teams use a distinct prefix.
The database table names follow the pattern: AS_[Solution]_[Module]_[Table Type]_[Table Name]
.
The Appian objects in the application follow the pattern: AS_[Solution Name]_[Module]_[ObjectType]_[ObjectDescription]
.
The Solution prefix options in the application are:
Module prefixes indicate that certain tables or objects all relate to the same functionality. For example, if you're looking for all tables that affect the KYC questionnaire functionality, QNM will indicate that those tables are related.
The main module prefixes in the application are:
Abbreviation | Module Reference |
---|---|
QNM | Questionnaire Management |
CHS | Companies House |
CS | Consolidated Screening (OFAC) |
IDP | Intelligent Document Processing |
TMG | Task Management |
ALT | Alert Management |
RC | Record Comments |
Table type prefixes are specific to the database tables and indicate what the table is used for.
If a table does not have a table type prefix, it is used as a transactional table. Reference (R) tables hold data that is relatively static and generally used for populating other fields or tables, while template (T) tables hold data that will generate a Onboarding.
For example, reference data from the generic AS_FS_R_DATA
table is used to populate the Document Type dropdown menu, which allows users to classify default required documents associated with an onboarding template by selecting from a list of available document types. When the documents are configured on a template, they are added to the AS_IO_T_REQUIRED_DOCUMENT
table. Finally, when the required documents are generated at runtime from the onboarding template, they are stored in the AS_IO_REQUIRED_DOCUMENT
table.
Note that there can be audit tables for each level of data as well. For example, the AS_FS_R_DATA
table is audited with the AS_FS_REF_A_R_DATA
table, the AS_IO_T_REQUIRED_DOCUMENT
table with the AS_IO_A_T_REQUIRED_DOCUMENT
table, and the AS_IO_REQUIRED_DOCUMENT
table with the AS_IO_A_REQUIRED_DOCUMENT
table.
The table type prefixes are:
Abbreviation | Table Type |
---|---|
Transactional | |
A | Audit |
R | Reference |
T | Template |
A_R | Audit Reference |
A_T | Audit Template |
Object prefixes indicate what type of Appian object is being used in order to help the user understand what is in the object before opening it.
The object type prefixes are:
Abbreviation | Module Reference |
---|---|
CRD | Card |
SCT | Section |
GRD | Grid |
BTN | Button |
BL | Business Logic |
WA | Web API |
CP | Component |
CPS | Components |
FM | Form |
QE | Query Entity |
QR | Query Rule |
DSP | Display rule |
UT | Utility rule |
UI | UI component for expression rules |
UNMAPPED | CDT that does not have a DB table |
ENUM | Enumeration |
FLD | Folder |
APPREF | Application reference |
HCL | Header content layout |
SBS | Side by side layout |
SCT | section layout |
ENT | Entity |
TST | Test (object used for testing, for example, to populate a test case) |
VAL | Text value |
VLD | Validation |
Common objects are objects that are used across the application to help with logic or formatting used consistently. These objects are prefixed with CO
. Don't change these objects as they are used multiple places and can cause issues.
Some objects may no longer be used within the application, but are included due to potential application upgrade conflicts. These objects will all be prefixed with zzz_DEPRECATED
.
The Connected Onboarding solution can be translated into multiple languages. Note that certain UI text for Connected Onboarding's interfaces are contained in bundle files. For example, labels, validation messages, tooltips, and instructional text all exists in bundle files. To update this UI text, you update the bundle file that is associated with it.
Note that some dropdown list values are contained in reference data tables. To modify this type of UI text, see Modifying Dropdown Lists. Keep in mind that user-entered text always displays in whatever language the user entered.
In order to display UI text, the Connected Onboarding application loads the correct language bundle (or document file) based on the default language that the user has selected.
It is important that each default language available for users to select has a corresponding set of bundle files. For example, if users can select English (United States) or Español from settings, there must be corresponding bundle files for each of these languages.
For interfaces that are in the AS IO Full Application application, you need to load the entire bundle onto the form to load the UI text onto the interface. You can do this by using a local variable with the rule!AS_IO_UT_loadI18nBundles
expression rule.
The only parameter you need to pass in is called triggerRefresh
. Under most circumstances, triggerRefresh
can be passed as null.
The triggerRefresh
parameter is only needed in cases where internationalization data needs to be reloaded after the user completes an action. For example, after a user adds new dropdown values from the front end the triggerRefresh
should be a variable that is updated on completion of that action.
EXAMPLE
1
2
3
4
5
a!localVariables(
local!i18nData: rule!AS_IO_UT_loadI18nBundles(
triggerRefresh: null
)
)
The rule!AS_IO_UT_loadI18nBundles
expression rule will automatically take into account the user's language and load the correct UI text. It's recommended that you call this rule in the main form and pass the UI text data to the sub-interfaces as a rule input. Name the rule input i18nData
and make the Type anyType
.
To display UI text on an interface, for the parameter that specifies the text to display, such as the label parameter, use the rule!AS_CO_I18N_UT_displayLabel
expression rule. In the following example, the UI will display Screening Results, which is the value of the lbl_ScreeningResults
label key in the bundle file.
The value of the bundleKey
parameter is created using:
AS.IO.AllBundles
.lbl_NoCountriesAvailable
.The bundleKey parameter in this example would look like: AS.IO.AllBundles.lbl_NoCountriesAvailable
.
1
2
3
4
5
6
7
8
...
local!i18nData:rule!AS_FS_UT_loadI18nBundles(triggerRefresh: null),
a!formLayout(
label: rule!AS_CO_I18N_UT_displayLabel(
i18nData: local!i18nData,
bundleKey: "AS.IO.AllBundles.lbl_NoCountriesAvailable"
)
)
To update the text or languages in the bundles files, use the Solutions Customization Suite.
It is also possible to download the bundle file documents directly and update them manually. Be sure to update a bundle file for each language.
The bundle files that are shipped with Connected Onboarding are as follows:
AS.IO.AllBundles
AS.QNM.QuestionnaireSettings
AS.QNM.QuestionnaireSettings
AS.QNM.Question
AS.QNM.QuestionnaireStatusCodes
AS.QNM.ResponseRequirements
AS.QNM.Questionnaire
AS.QNM.QuestionTypes
AS.QNM.QuestionnaireStatusCodes
AS.QNM.QuestionTypes
AS.QNM.ResponseRequirements
AS.QNM.Question
AS.QNM.Questionnaire
The prefix explanations above also apply to these bundle files. Any bundle file with an FS
prefix is a shared file and all references to that label across solutions will be updated.
Connected Onboarding Architecture Overview