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 guides.

Connected Underwriting P&C sites

Connected Underwriting P&C 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 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 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 P&C 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 P&C 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 P&C’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 P&C 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 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.
• “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 P&C. 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.

The Messaging 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:

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 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 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 all exist in translation set string files. To update this UI text, you update the associated translation set string file.

However, some dropdown list values are stored reference data tables that are limited to a single language. If you want to change the dropdown values, you need to 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

In order 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 can select English (United States) or Español from settings, there must be corresponding translation set string files for each of these languages.

To use translation set strings in interfaces and expression rules, simply 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 that you integrate with your Connected Underwriting P&C ship with their own translation sets.

Feedback