Connected Servicing Architecture Overview

Introduction

Use this page as a way to get familiar with the Connected Servicing 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 Servicing Sites

Connected Servicing has three main sites, each targeted at a different user group.

1. Connected Servicing: The primary site for all users of the solution. This is where user groups will view their tasks, reports, and records.
2. Connected FS Settings: This site is for business power users of the solution. The groups using this site are responsible for setting up the main Service Request processes and data.
3. System Admin Center: This site is for IT users that typically would have designer or administrator access for the Appian install. This site hosts integration status and toggles for easily turning the integrations on or off.

Primary records and relationships

Connected Servicing uses Appian records and record relationships to power the Service Request processes. The two main records included in the Connected Servicing solution are: Customer and Service Request records.

Customer records are the highest level of records in the solution and can have many Service Request events. Any piece of runtime data is going to be related to either of these two records.

Explanation of prefixes

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 Servicing 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].

Solution Prefixes

The Solution prefix options in the application are:

• SRQ: indicates that the database table or object is used for the Connected Servicing solution only.
• FS (Financial Services): indicates that the database table or objects is a global Financial Services table. Shared FS tables and objects are especially important when there are multiple FS solutions on the environment or planned to be on the environment as all of the FS solutions will share the table.
• CO (Common Objects): indicates that this is an object that is a commonly reused rule throughout the application. These objects are used for consistency throughout the application and across any Connected FS solutions that are in the environment.

Module Prefixes

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:

Table Type Prefixes

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 Service Request.

For example, reference task behavior types from the AS_TMG_R_TASK_BEHAVIOR_TYPE table is used to populate the dropdown list of behavior types when configuring reference tasks. These tasks, stored in the AS_TMG_R_TASK_REF table, are then used to populate a list of tasks that can be added to service request templates. Tasks associated with the service request are generated at runtime and stored in the AS_TMG_TASK table.

Note that there can be audit tables for each level of data as well. For example, the AS_TMG_R_TASK_REF table is audited with the AS_TMG_A_R_TASK_REF table, the AS_TMG_R_TEMPLATE_TASK table with the AS_TMG_A_R_TEMPLATE_TASK table, and the AS_TMG_TASK table with the AS_TMG_A_TASK table.

The table type prefixes are:

Object Type Prefixes

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:

Common objects

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.

Deprecated objects

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.

Internationalization

The Connected Servicing solution can be translated into multiple languages. Note that certain UI text for Connected Servicing'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.

Using bundle files

In order to display UI text, the Connected Servicing 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 SRQ 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_SRQ_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_SRQ_UT_loadI18nBundles( 
    triggerRefresh: null
  )
)

The rule!AS_SRQ_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:

• The name of the bundle file, without the language suffix (en_us). For example: AS.SRQ.AllBundles.
• The label key for the value that you want to display. For example: lbl_NoCountriesAvailable.

The bundleKey parameter in this example would look like: AS.SRQ.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.SRQ.AllBundles.lbl_NoCountriesAvailable" 
    )
  )

Updating bundle file text

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.

Default bundle files

The bundle files that are shipped with Connected Servicing are as follows:

• AS.SRQ.AllBundles
• AS.TMG.AllBundles

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.

Feedback