Connected Underwriting Architecture Overview

Introduction

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.

Connected Underwriting sites

Connected Underwriting has two key sites:

• Connected Underwriting: This is the primary site for all users of the solution. This is where users can view key records and take relevant actions to advance business workflows.
• Connected Underwriting Settings: This site is for business power users of the solution. The groups using this site can set key settings about how larger functionality is set within the solution.

Primary records and relationships

Connected Underwriting uses Appian records and record relationships to power the Underwriting processes.

Transactional record overview

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:

• Submission Decision: This record represents the single decision an Underwriter may ultimately make for a Submission.
• Threadset: This record represents the link between Submissions and Messaging-related records.

The Submission record has one-to-many relationships with the following records:

• Submission LOB: This record represents the Lines of Business (LOB) a Submission is related to. This record has additional one-to-many relationships with other transactional records, depending on the LOB type the Submission is listed under. This record also has a relationship with the transactional Priority Score Outcome record, which is used to calculate priority for a particular Submission.
• Submission Document: This record represents various Documents that may be attached to a Submission.
• Task: This record represents Tasks that can be created and completed for a Submission.
• Alert: This record represents Alerts that may be automatically generated through user action with a Submission.
• Submission Note: This record represents Notes created by a user on a Submission.
• Submission Watcher: This record represents users who are watchers on a Submission.
• Submission Event Audit: This record represents distinct historical events/actions which have taken place on a Submission.

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:

• Customer: This record represents the actual Customer which a Submission is for.
• Broker: This record represents the Broker who submitted the Submission on behalf of the Customer.
• Broker Office: This record represents the Broker Office for a specific Broker.

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:

• Thread: This record represents the sole thread relating to the corresponding Threadset for a Submission.
• Message: This record represents a single message in any thread for a Submission.
• Thread Recipient: This record represents all current recipients for a specific messaging thread for a Submission.
• Message Recipient: This record represents the specific recipients for a Message at the time a message was sent.
• Message Attachment: This record represents attachments for a Message.

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:

• Message Exception: This record holds exceptions relating to incoming emails which could not be attached to a particular Submission.
• Extraction Reconciliation Exception: This record holds reconciliation exceptions for documents that need to be manually reconciled by a user before final information is extracted and saved from a document that underwent IDP extraction.
• Classification Exception: This record holds exceptions for documents that need to be classified correctly after uncertain or failed IDP classification of documents.
• Submission Document Extraction: This record holds the extracted, reconciled values from a document extraction attempt.

Reference record overview

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:

• Reference Document Type: This record contains reference data for Submission Document types and information about the extractability of such documents.
• Reference Status: This record contains reference data for different statuses of a Submission and whether certain types of Submission edits are allowed.

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:

• Reference Alert Configuration, Alert Set, and Alert Condition: The set of records used for controlling how Alerts are generated for a Submission.
• Reference Scoring Set, Scoring Condition, and Scoring Set LOB: The set of records used for holding information relating to Scoring Tables.
• Reference Priority Set and Priority-Scoring Map: The set of records used for holding Submission Scoring Rules and mapping individual Scoring Sets to a Priority Scoring rule.

Usage of Records and Limitations

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.

Naming conventions

The following items demonstrate Connected Underwriting’s standard naming conventions for objects and tables related to the solution:

CDT

• Pascal casing with appropriate prefixes.

Examples

ISU_(CDTName)

• ISU_T_InboundEmailAttachmentMSGraph
• ISU_UNMAPPED_DynamicContext

Record

• Snake case with proper naming.
• “Record” prefix always used.
• “R” prefix used for reference records.

Examples

ISU_Record_(Record_Name)

• ISU_Record_Submission
• ISU_Record_Broker_Office
• ISU_Record_R_Alert_Config

Expression

• Camel casing.

Examples

ISU_(expressionRuleName)

• ISU_createRecordSubmission
• ISU_updatePropertySubjectFks

Interface

• Camel casing.

Examples

ISU_(interfaceName)

• ISU_tasksList
• ISU_completeMessageException

Querying

• Camel casing with appropriate “QR” or “QE” prefix, depending on entity or record being queried.

Examples

ISU_(QR or QE)_get(Entities)

• ISU_QR_getSubmissionWatchers
• ISU_QE_getInboundEmailMsGraphBody

Process Model

• Proper naming.

Examples

ISU (Process Model Name)

• ISU Extract Document
• ISU Edit Auto Risk Info

Site

• Snake case with proper naming.

Examples

ISU_Site_(SiteName)

• ISU_Site_ConnectedUnderwriting

Constant

• Screaming snake case with appropriate type of constant as prefix.

Examples

ISU_(TYPE)_(CONSTANT_NAME)

• ISU_REF_CODE_DOCUMENT_TYPE_PACKET
• ISU_TXT_NEW_LINE

Folder

• Proper naming.

Examples

ISU (Folder Name)

• ISU Branding Files
• ISU Process Reports

Group

• Proper naming

Examples

ISU (Group Name)

• ISU Administrators
• ISU Managers

Data Store

• Proper naming.

Examples

ISU (Data Store Name)

• ISU Transactional Data
• ISU Reference Data

Database Tables and Columns

• Screaming snake case with “T” or “R” prefix for tables.

Examples

ISU_(T or R)_(TABLE_NAME)

• ISU_T_SUBMISSION_LOB
• ISU_R_DATA
• SUBMISSION_ID

Variables and Rule Inputs

• Camel casing.
• Use plural name to indicate an array.

Examples

(variableName) or (variableNames>)

• submissionLob
• submissionDocuments

Field Names

• Camel casing.

Examples

(fieldName)

• submissionId
• createdBy

Prefixes

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.

• 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

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

Table type prefixes are specific to the database tables and indicate what the table is used for.

• Reference (R): Tables holding data that is relatively static and generally used for populating other fields or tables.
• Transactional (T): Tables holding data that is often modified and created by front-end users.

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.

Object Type Additional Prefixes

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:

Common Objects

Common Objects are used consistently across the application to help with logic or formatting. These objects are prefixed with CO.

Deprecated Objects

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.

Internationalization

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.

Using Bundle Files

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.

EXAMPLE

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:

• The name of the bundle file, without the language suffix (en_us). For example: AS.ISU.AllBundles.
• The label key for the value that you want to display. For example: lbl_Country.
  • The bundleKey parameter in this example would look like: AS.ISU.AllBundles.lbl_Country.

EXAMPLE

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" 
    )
  )

Updating Bundle File Text

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.

Default Bundle Files

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

Feedback