This content applies solely to Connected Underwriting, which must be purchased separately from the Appian base platform. This content was written for Appian 23.4 and may not reflect the interfaces or functionality of other Appian versions. |
This page outlines and explains the patterns developed by the Appian Solutions developers to make it easy to navigate and understand the application when making changes. You can find additional examples that show how to customize and modify your solution in the Modifying Connected Underwriting guides.
Note: For the purpose of this document, the terms Priority Scoring and Submission Scoring are used interchangeably and refer to the Submission Scoring rules and associated objects.
Connected Underwriting has two key sites:
Connected Underwriting uses Appian records and record relationships to power the Underwriting processes.
The primary transactional record used throughout the solution is the Submission record.
The Submission record has relationships with multiple other, more minor transactional records, including one-to-one relationships with the following records:
The Submission record has one-to-many relationships with the following records:
Sitting levels above the Submission record are the Customer, Broker, and Broker Office records. The Submission record has a many-to-one relationship with both the Customer and Broker records, and the Broker record has a many-to-one relationship with the Broker Office records:
In addition to these, there exists a variety of transactional records relating to the Messaging module. The key transactional records involved with Messaging functionality are the following:
Lastly, there exists transactional records relating to the email and IDP workflow for this application. These records host attempted IDP extractions and exception flows for emails and documents that come into the application which could not be processed automatically. These include:
In addition to the transactional records described above, Connected Underwriting leverages the use of Reference records to hold data to be displayed and stored for transactional purposes.
The primary record is the Reference Data record, which holds unique codes and corresponding front-end display labels for such data. This record should strictly be inserted into and updated by developers, and front-end control of this record should be limited only to data reads.
Individual records also exist for more complicated pieces of reference data, which capture additional pieces of metadata that the Reference Data record cannot capture on its own. These types of reference tables include:
There also exist reference records which may be interacted with and controlled by business administrators through the Connected Underwriting Settings page. These reference records provide a means for controlling larger business logic in processes, and though they are transactional in the sense that front-end users have control over at least some of the data in them, they are named and treated as reference records considering their larger business implications. More specifically, these records are used in the configuration of Alerts and Priority Score and Scoring Sets:
Much of Connected Underwriting’s technical design and functionality is driven by the core records described above. Records, and specifically, synced records, are used consistently in expressions, interfaces, and process models, instead of CDTs; both data writes and data reads leverage record data types.
As of Appian 22.3, there exists a 2,000,000 row limit that can be synced on a synced record. Connected Underwriting currently assumes that volumes should be low enough so that no more than this number of rows will exist for any particular table.
In addition to this, records often use a source filter to prevent soft-deleted data from the database from syncing in an additional attempt to keep data volumes under this maximum. There are also limitations on the size of fields which can be synced through records. Because this application contains a few long text fields on particular tables which exceed this size, these fields are read and written using CDTs.
The following items demonstrate Connected Underwriting’s standard naming conventions for objects and tables related to the solution:
ISU_(CDTName)
ISU_T_InboundEmailAttachmentMSGraph
ISU_UNMAPPED_DynamicContext
ISU_Record_(Record_Name)
ISU_Record_Submission
ISU_Record_Broker_Office
ISU_Record_R_Alert_Config
ISU_(expressionRuleName)
ISU_createRecordSubmission
ISU_updatePropertySubjectFks
ISU_(interfaceName)
ISU_tasksList
ISU_completeMessageException
ISU_(QR or QE)_get(Entities)
ISU_QR_getSubmissionWatchers
ISU_QE_getInboundEmailMsGraphBody
ISU (Process Model Name)
ISU Extract Document
ISU Edit Auto Risk Info
ISU_Site_(SiteName)
ISU_Site_ConnectedUnderwriting
ISU_(TYPE)_(CONSTANT_NAME)
ISU_REF_CODE_DOCUMENT_TYPE_PACKET
ISU_TXT_NEW_LINE
ISU (Folder Name)
ISU Branding Files
ISU Process Reports
ISU (Group Name)
ISU Administrators
ISU Managers
ISU (Data Store Name)
ISU Transactional Data
ISU Reference Data
ISU_(T or R)_(TABLE_NAME)
ISU_T_SUBMISSION_LOB
ISU_R_DATA
SUBMISSION_ID
(variableName) or (variableNames>)
(fieldName)
submissionId
createdBy
Specific prefixes are used for consistency and 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.
ISU
is the prefix for all objects and database tables created and included in Connected Underwriting. This will help differentiate objects that were shipped as part of the solution.
Note: It is recommended that implementation teams use a distinct prefix for custom objects.
Database table names follow the pattern: ISU_[Table Type][Module][Table Name].
The Appian objects in the application follow the pattern: ISU_[Module][ObjectType][ObjectDescription].
Module prefixes indicate that certain tables or objects all relate to the same functionality.
Currently, the only module used in Connected Underwriting is the Messaging module. This module provides the functionality for creating and attaching user-generated messages to a particular Submission. Objects and tables related to this module use the prefix MSG
.
Table type prefixes are specific to the database tables and indicate what the table is used for.
The “R” prefix is used additionally in the naming convention for defining corresponding record types, but transactional records drop the “T” prefix that should be contained in their corresponding database table.
Additional prefixes may be appended to objects and constants to help better indicate what type of object is being used and to aid the user in understanding what an object is before opening it.
Examples of additional prefixes and their object types are:
PREFIX | OBJECT TYPE |
---|---|
AGG | Aggregation |
CP | Component |
CONF | Configuration |
DOC | Document |
DSE | Data Store Entity |
ENUM | Designer defined enumeration |
EXTRACTION | Indicates a CDT that is used for document extraction via IDP |
GRP | Group |
INT | Integer |
PM | Process Model |
REF_CODE | Reference code from a referential database table |
REF_TYPE | Reference type from the main Reference Data database table |
TXT | Text |
UNMAPPED | Used to indicate a CDT is not mapped to any database table |
USER_ACTION | A type of user action; often used for button labels |
UT | Utility function |
Common Objects are used consistently across the application to help with logic or formatting. These objects are prefixed with CO
.
Caution: Don't change CO objects, as they are used multiple places and can cause issues.
Deprecated 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 ISU_DEPRECATED
.
Connected Underwriting can be translated into multiple languages. Note that certain UI text for Connected Underwriting interfaces are contained in bundle files. For example, labels, validation messages, tooltips, and instructional text all exist in bundle files. To update this UI text, you update the associated bundle file.
Note that some dropdown list values are contained in reference data tables. Keep in mind that user-entered text always displays in whatever language the user entered.
In order to display UI text, Connected Underwriting loads the correct language bundle (or document file) based on the default language the user has selected. It is important that each default language available for users 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, 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!ISU_UT_loadI18nBundles
expression rule.
The only parameter you need to pass in is called triggerRefresh. Under most circumstances, triggerRefresh can be passed as now().
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 updated on completion of that action.
1
2
3
4
5
6
a!localVariables(
local!i18nData: rule!ISU_UT_loadI18nBundles(
triggerRefresh: now()
)
…
)
The rule!ISU_UT_loadI18nBundles
expression rule will automatically take into account the user's language and load the correct UI text. It is 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 data 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!ISU_CO_I18N_UT_displayLabel
expression rule. In the following example, the UI will display “Country”, which is the value of the lbl_Country
label key in the bundle file.
The value of the bundleKey parameter is created using:
AS.ISU.AllBundles
.lbl_Country
.
AS.ISU.AllBundles.lbl_Country
.1
2
3
4
5
6
7
local!i18nData:rule!ISU_UT_loadI18nBundles(triggerRefresh: now()),
a!formLayout(
label: rule!ISU_CO_I18N_UT_displayLabel(
i18nData: local!i18nData,
bundleKey: "AS.ISU.AllBundles.lbl_Country"
)
)
To update the text or languages in the bundle 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 Underwriting are as follows, with the prefix explanations above also applying to these bundle files:
AS.ISU.AllBundles
AS.MSG.AllBundles
Connected Underwriting Architecture Overview