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 P&C content.

Connected Underwriting P&C sites

Connected Underwriting P&C has two key sites:

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

Primary records and relationships

Connected Underwriting P&C 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 records, more minor transactional records, and 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) related to a submission. Depending on the LOB type under which the Submission is listed, this record has additional one-to-many relationships with other transactional records. 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 and actions that have taken place on a Submission.

The Customer, Broker, and Broker Office records are sitting above the Submission record. 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 customer for 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, a variety of transactional records relating to the Messaging module exists. 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, this application has transactional records relating to the email and IDP workflow. 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 to incoming emails that 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 P&C leverages 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. Developers should strictly insert and update this record, and front-end control should be limited only to data reads.

Individual records also exist for more complicated pieces of reference data, which capture additional metadata that the Reference Data record cannot capture independently. These types of reference tables include:

Reference Document Type: This record contains reference data for submission document types and information about their extractability. Reference Status: This record contains reference data for different submission statuses 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 P&C Settings page. These reference records provide a means for controlling larger business logic in processes. 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

The core records described above drive much of Connected Underwriting P&C’s technical design and functionality. Records, specifically synced records, are consistently used instead of CDTs in expressions, interfaces, and process models; both data writes and data reads leverage record data types.

As of Appian 22.3, a 2,000,000 row limit can be synced on a synced record. Connected Underwriting P&C assumes that volumes should be low enough so that no more than this number of rows will exist for any table.

In addition, records often use a source filter to prevent soft-deleted data from the database from syncing, another attempt to keep data volumes under this maximum. There are also limitations on the size of fields that can be synced through records. Because this application contains a few long text fields on particular tables that exceed this size, these fields are read and written using CDTs.

Naming conventions

The following items demonstrate Connected Underwriting P&C’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.
• The “Record” prefix is always used.

• The “R” prefix is 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 the 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 the appropriate type of constant as a 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 names 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 to give a high-level understanding of the object or database table. Prefixes indicate where the object is used and what it is used for.

ISU is the prefix for all objects and database tables created and included in Connected Underwriting P&C. This will help differentiate objects 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 relate to the same functionality.

The Messaging module allows users to create and attach 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 relatively static data are generally used for populating other fields or tables.
• Transactional (T): Tables holding data often modified and created by front-end users.

The “R” prefix is additionally used in the naming convention to define corresponding record types. Still, 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 better indicate what type of object is being used and to help the user understand 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

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

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 P&C can be translated into multiple languages. Note that certain UI text for Connected Underwriting P&C interfaces are contained in translation set string files. For example, labels, validation messages, tooltips, and instructional text exist in translation set string files. You update the associated translation set string file to update this UI text.

However, some dropdown list values are stored in reference data tables limited to a single language. To change the dropdown values, you must first update the corresponding values in the underlying database table. It's important to note that user-entered text will always appear in the language that the user entered.

Using Translation Set String files

To display UI text, Connected Underwriting P&C loads the correct language translation set string (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 translation set string files. For example, if users choose English (United States) or Español from settings, there must be corresponding translation set string files for each language.

To use translation set strings in interfaces and expression rules, reference the correct translation set string from the corresponding translation set by using the prefix translation! and searching for the desired string. On the front end, the string will be loaded in the language corresponding to the logged-in user’s locale settings.

Updating Translation Set String file text

To update the text or languages in the translation set string files, change the text of the corresponding translation set string in Appian Designer.

It is also possible to download the translation set string file documents directly and update them manually. Be sure to update the value of a translation set string for each language.

Default Translation Set String files

The sole translation set string file shipped with Connected Underwriting P&C is named ISU_Translations. This file contains all strings that are referenced in the application.

It is important to note that any add-on modules you integrate with your Connected Underwriting P&C ship with their own translation sets.

Feedback