IIF ImpGuide V33

Insurance Industry Framework
Implementation Guide
© Copyright 2008
Pegasystems Inc., Cambridge, MA
All rights reserved.
This document describes products and services of Pegasystems Inc. It may contain trade
secrets and proprietary information. The document and product are protected by copyright
and distributed under licenses restricting their use, copying distribution, or transmittal in any
form without prior written authorization of Pegasystems Inc.
This document is current as of the date of publication only. Changes in the document may be
made from time to time at the discretion of Pegasystems. This document remains the
property of Pegasystems and must be returned to it upon request. This document does not
imply any commitment to offer or deliver the products or services described.
This document may include references to Pegasystems product features that have not been
licensed by your company. If you have questions about whether a particular capability is
included in your installation, please consult your Pegasystems service consultant.
For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or
product names are trademarks of their respective holders.
Although Pegasystems Inc. strives for accuracy in its publications, any publication may
contain inaccuracies or typographical errors. This document or Help System could contain
technical inaccuracies or typographical errors. Changes are periodically added to the
information herein. Pegasystems Inc. may make improvements and/or changes in the
information described herein at any time.
This document is the property of:

Pegasystems Inc.
101 Main Street
Cambridge, MA 02142-1590
(617) 374-9600, fax: (617) 374-9620
www.pega.com

Document: Implementation Guide
Software Version: 3.3
Updated: June 2008

Contents
Chapter 1: Before You Begin .............................................................................................. 1-1
What Is the Insurance Industry Framework? ................................................................... 1-2
Insurance Industry Framework ................................................................................. 1-3
Understanding the Insurance Product ............................................................................. 1-4
Insurance Products .................................................................................................. 1-4
Insurance Components ............................................................................................ 1-5
Your Framework and Process Commander .................................................................... 1-6
Who Should Read This Document? ................................................................................ 1-7
Education and Training ............................................................................................ 1-7
Other Information to Read ............................................................................................... 1-8
Chapter 2: Deploying the Framework ................................................................................. 2-1
Documenting Your Application ........................................................................................ 2-2
Creating a New RuleSet .................................................................................................. 2-4
Creating a RuleSet Version ............................................................................................. 2-5
Adding Your RuleSet to the Administrator’s Access Group ............................................. 2-6
Creating Your Top-Level Class ....................................................................................... 2-7
Copying the Work Class Group to Your Class Hierarchy ................................................ 2-8
Copying the Data-Admin-DB Table Instances ................................................................. 2-9
Setting Up Calendars .................................................................................................... 2-10
Setting Up Correspondence .......................................................................................... 2-11
Sample HTML and Template ................................................................................. 2-13
Printing and Faxing ....................................................................................................... 2-14
Setup Requirements Before Extending ......................................................................... 2-15
Chapter 3: What Is Already Set Up .................................................................................... 3-1
System Administrator Account ........................................................................................ 3-2
RuleSet Hierarchy ........................................................................................................... 3-3
Class Structure ................................................................................................................ 3-5
Class Inheritance ..................................................................................................... 3-5
Class Structure for Work Objects ............................................................................. 3-6
Data Classes ................................................................................................................... 3-7
Interface Classes............................................................................................................. 3-8
PegaIns-Interface-InsurancePolicy .......................................................................... 3-8
PegaIns-Interface-PolicyLink.................................................................................... 3-8
PegaIns-Interface-AgencyLOB................................................................................. 3-8
iv Insurance Industry Framework
PegaIns-Interface-Contact ....................................................................................... 3-8

PegaIns-Interface-Roles .......................................................................................... 3-9
Data-Admin-DB-Table .............................................................................................. 3-9
Work Object Naming Conventions ................................................................................ 3-10
Default Work Groups and Workbaskets ........................................................................ 3-11
Default Operators and Access Groups .......................................................................... 3-12
Predefined Access Roles and Privileges ....................................................................... 3-13
Predefined Work Parties ............................................................................................... 3-14
Correspondence Templates .......................................................................................... 3-15
Process Commander Templates ............................................................................ 3-15
Framework Templates ........................................................................................... 3-16
Sample Data to Test Use Cases ................................................................................... 3-17
Contact Search.............................................................................................................. 3-18
Policy Search ................................................................................................................ 3-22
Policy Search Implementation ................................................................................ 3-22
Search Types and Implementation Rules .............................................................. 3-23
Chapter 4: Extending the Framework ................................................................................. 4-1
Extending the Work Class Structure................................................................................ 4-2
Inheriting from the PegaIns-Work- class .................................................................. 4-3
Creating New Work Flows ........................................................................................ 4-6
Integrating with Systems of Record and Policy Administration systems .................. 4-7
Extending the Data Class Structure ................................................................................ 4-8
Inheriting from the PegaIns-Data- Class Structure ................................................... 4-9
Underwriting rules .................................................................................................. 4-11
Inheriting from the PegaIns-Interface- Class Structure .......................................... 4-12
Working with Insurance Work Objects........................................................................... 4-13
Application – New Business ................................................................................... 4-13
Understanding the Preconfigured Workflows ......................................................... 4-25
ChgPolicy – Endorsements .................................................................................... 4-28
Configuration of Products (Policies) ....................................................................... 4-37
Pricing Details ........................................................................................................ 4-40
Agencies and Agents .................................................................................................... 4-41
Agencies ................................................................................................................ 4-42
Agents .................................................................................................................... 4-42
Agent Profiles ......................................................................................................... 4-42
Associating Agencies to Policies ............................................................................ 4-43
Insurance Industry Framework v
Sample Agent and Agency Data ............................................................................ 4-45

Matching Drivers to Vehicles ......................................................................................... 4-48
How the Framework Associates Drivers to Vehicles .............................................. 4-50
Chapter 5: Pricing Rules and Models ................................................................................. 5-1
Pricing Overview ............................................................................................................. 5-2
Standard Pricing Rules.................................................................................................... 5-4
Pricing Activities in the Framework .......................................................................... 5-4
Pricing activities in the PegaSP Class...................................................................... 5-6
Business Policy Owner’s Product Pricing Model ............................................................. 5-8
Term Life Pricing Model ................................................................................................ 5-12
Variable Universal Life Pricing Model ............................................................................ 5-13
Automotive Pricing Model.............................................................................................. 5-18
Personal Auto......................................................................................................... 5-18
Commercial Auto.................................................................................................... 5-20
Homeowners Pricing Model .......................................................................................... 5-21
Chapter 6: Interfacing with External Systems .................................................................. 6-1
Integrating Contact Data ................................................................................................. 6-2
Reading Contact Data Rules .................................................................................... 6-2
Writing Contact Data Rules ...................................................................................... 6-3
Searching Contact Data Rules ................................................................................. 6-4
Integrating Policy Data .................................................................................................... 6-5
Writing Policy Rules ................................................................................................. 6-5
Reading Policy Rules ............................................................................................... 6-7
Searching Policy Rules ............................................................................................ 6-8
Integrating Agent and Agency Data ................................................................................ 6-9
Chapter 7: Processing ACORD XMLMessages.................................................................. 7-1
ACORD Processing Flow and Architecture ..................................................................... 7-2
ACORD Processing Rules .............................................................................................. 7-4
General Rules .......................................................................................................... 7-5
Parsing Rules ......................................................................................................... 7-11
Application Specific Rules ...................................................................................... 7-13
Building Rule-Obj-XML rules ......................................................................................... 7-19
Adding a New Product................................................................................................... 7-20
Sample Messages ......................................................................................................... 7-22
Appendix A: Database Tables ............................................................................................. A-1
vi Insurance Industry Framework
Database Tables ............................................................................................................. A-2

IIF_POLICY ..................................................................................................................... A-3
Columns ................................................................................................................... A-3
Constraints ............................................................................................................... A-6
Large Object (LOB) Storage Attributes .................................................................... A-7
Referencing Tables and Columns ............................................................................ A-7
IIF_POLICY_LINK ........................................................................................................... A-8
Columns ................................................................................................................... A-8
Constraints ............................................................................................................. A-10
Foreign Key Relationships ..................................................................................... A-11
IIF_AGENCY_LOB ........................................................................................................ A-12
Columns ................................................................................................................. A-12
Constraints ............................................................................................................. A-13
PA_ADDRESS .............................................................................................................. A-14
Columns ................................................................................................................. A-14
Constraints ............................................................................................................. A-15
PA_ADDRESS_TYPE ................................................................................................... A-17
Columns ................................................................................................................. A-17
Constraints ............................................................................................................. A-17
Referencing Tables and Columns .......................................................................... A-18
PA_BUSINESSUNIT ..................................................................................................... A-19
Columns ................................................................................................................. A-19
Constraints ............................................................................................................. A-21
PA_BUSINESSUNIT_LINK ........................................................................................... A-23
Columns ................................................................................................................. A-23
Constraints ............................................................................................................. A-24
PA_COMMUNICATION_OPTIONS .............................................................................. A-25
Columns ................................................................................................................. A-25
Constraints ............................................................................................................. A-26
PA_COMMUNICATION_TYPES ................................................................................... A-28
Columns ................................................................................................................. A-28
Constraints ............................................................................................................. A-29
Insurance Industry Framework vii
PA_CONTACT .............................................................................................................. A-31

Columns ................................................................................................................. A-31
Constraints ............................................................................................................. A-33
PA_CONTACT_BUSINESSUNIT_LINK ........................................................................ A-35
Columns ................................................................................................................. A-35
Constraints ............................................................................................................. A-36
PA_CUSTOMER_TYPE ................................................................................................ A-38
Columns ................................................................................................................. A-38
Constraints ............................................................................................................. A-39
PA_INDUSTRY ............................................................................................................. A-41
Columns ................................................................................................................. A-41
Constraints ............................................................................................................. A-42
PA_NOTES ................................................................................................................... A-43
Columns ................................................................................................................. A-43
Constraints ............................................................................................................. A-44
PA_PRODUCT .............................................................................................................. A-45
Columns ................................................................................................................. A-45
Constraints ............................................................................................................. A-46
PA_PRODUCT_TYPE .................................................................................................. A-47
Columns ................................................................................................................. A-47
Constraints ............................................................................................................. A-48
PA_ROLES ................................................................................................................... A-50
Columns ................................................................................................................. A-50
Constraints ............................................................................................................. A-51
viii Insurance Industry Framework
Chapter 1:
Before You Begin
This document describes how to install, deploy, and extend the Insurance
Industry Framework (IIF) for initial development and production use. It assumes
that:
■ PegaRULES Process Commander (Process Commander) is already installed
■ You have taken the appropriate training courses
■ Some team members are PegaRULES Process Commander certified
■ Some team members have business expertise at a detailed level in the

application areas to be supported (such as insurance products, agreements,
claims, business processes, and activities.)
■ Some team members understand the application and technology architecture

of the environment into which the Framework is to be deployed, including
interface requirements of related applications
1-2 Insurance Industry Framework Implementation Guide
What Is the Insurance Industry Framework?

The Insurance Industry Framework provides a best practice implementation of
basic insurance services to create insurance specific business applications,
reducing the development time to create new applications, mitigating project risk,
and decreasing the time to gain Return On Investment (ROI).
The Insurance Industry Framework has two components:
■ An insurance foundation that provides comprehensive partially attributed

class structures, properties, methods, common services, and basic workflows
and activities that span all lines of business and most of the insurance value
chain.
■ Starter Kits in three areas (Product Management, Acquiring and Retaining

Business) that provide high-level work templates, outline product
specifications, and screen flows that serve as best practice implementations,
leveraging the strengths of the Process Commander SmartBPM Suite to
maximize reusability. These serve as starting points to extend the
Framework and manage your specific business needs by means of
Pegasystems provided Insurance Solution Frameworks, your own custom
built applications, or some mix of both.
Integral to the Insurance Industry Framework is the capability for defining and
managing new products configurations. Pegasystems’ Product Configurator
Solution Framework is used in conjunction with this Framework to provide this
capability. These product specifications define the structure and valid
configurations of what maybe offered for sale in terms of insured objects,
coverages / benefits, services, etc., the business rules and calculations
surrounding the sale and servicing activities, and act as a model for each
instantiation of the product as a specific agreement as “bought” by a customer.
By externalizing product rules from manual and legacy systems, rules can be
more easily maintained by users. The Insurance Industry Framework can be the
system of record for such rules and activities and these can then be leveraged in
all insurance solutions that rely on detailed knowledge of the insurance product
or resulting agreement. However, the Insurance Industry Framework can also
access external rules engines and existing core administration applications if
expeditious to do so, as long as the basic product / agreement hierarchical
structure is defined in the Insurance Industry Framework for each product type –
since this is used to drive screen and workflows, data mapping, and structure
work objects correctly.
Before You Begin 1-3

The Insurance Industry Framework:
■ Provides a foundation that services a range of business process

management applications including acquiring and retaining business (new
business, endorsements, underwriting), claims and product management
■ Provides the ability to define Product Specifications used to create and

maintain individual agreements including the state of the agreement. (For
example, an agreement type work object may change from being a quote, to
a full offer for Products and Services, to a Binder, and then to a ratified
Agreement such as a Policy).
■ Enables circumstancing on date and jurisdiction on all relevant business

rules and activities so that these are used as workflows and activities are
executed. (For example, a quote maybe for a date in the future or past and
be valid for 30 days during which time changes maybe made – the rules in
effect for the desired start date must be correctly selected and used until the
case is resolved and the data no longer required).
■ Provides sample User Interfaces to enter basic product specifications, and

more detail products rules if no other option is selected (such as calling other
applications for services for licensing requirements, rating, and pricing).
■ Provides best-practice sample definitions of insurance parties, commonly

found product structures, agreements, and user interfaces.
■ Provides full support for the reuse of common product components,

workflows, services, and activities.
■ Provides industry data and process models covering most insurance lines of
business derived from IBM’s Insurance Application Architecture.
Note: The Insurance Industry Foundation includes assets derived from IBM
Insurance Application Architecture (IAA) models. Please refer to your license
agreement for the Insurance Industry Framework for restrictions on the use of
these assets.
Understanding the Insurance Product

An insurance product is created by defining both a product and its components.
Pegasystems Product Configuration Solution Framework is a horizontal solution
that when combined with the Insurance Industry Framework, enables you to
define products (saleable packages of insurance coverages / benefits and
services) in terms of standard and optional packages, components,
subcomponents, and features. This combination also provides the capability to
rapidly develop, maintain, and uniquely deploy product (or service) specifications
in a controlled and consistent manner.
See the Product Configuration Framework Installation and Deployment Guide for
more information about the Product Configuration Solution Framework. This
Framework is included in the Insurance Industry Framework, is a prerequisite for
product management, and is used to acquire and retain business product
functionality.
Following is a short description of some sample Insurance products that have

been created using a combination of the Product Configuration Framework rules
and activities and the Insurance Foundation class and attribute structure.
Insurance Products
Insurance products are specified as valid combinations of such things insured
objects (property, financial exposure, life, etc.), locations, coverages and
benefits, services, investments, and terms and conditions that can be quoted and
offered for purchase under a set of predetermined circumstances (who may buy /
sell / dates). They are at the level at which the purchase agreement is made. The
amount of detail that resides in the Insurance Industry Framework as the system
of record versus that held in other applications and called from Insurance
Industry Framework varies for each unique implementation.
The Insurance Industry Framework, leveraging the imbedded Product

Configuration Framework, provides specifications for some sample insurance
products. The Insurance Industry Framework also provides the associated work
object class structure and specialized workflows necessary to produce quotes,
offers to purchase, and agreements for each sample product type.
An insurance product may be specified to be a packaging of other products.

Examples of product specifications, class structures, and workflows in the

Insurance Industry Framework include:
■ Personal Lines Auto
■ Personal Lines Homeowners
■ Commercial Lines BOP (Business Owner’s Package)
■ Commercial Lines Auto
■ Term Life
■ Variable Universal Life
Note: These products contain key components and attributes only, they do
not represent complete product specifications.
Insurance Components
Components of the Insurance Product and derived quotation and agreements
include:
■ Jurisdictions
■ Locations
■ Insured objects (risk units)
■ Coverages / benefits
■ Risks
■ Terms and conditions
■ Investments
■ Services and fees.
Components may consist of other components (subcomponents). All

components can be shared across products if they are truly identical, or copied,
renamed, and modified if they are not identical. This greatly increases
productivity, reduces risk, and speeds implementation of changing business
needs.
A “where-used” capability is provided to assist with maintenance and

management of components that are shared or cloned.
Your Framework and Process Commander

PegaRULES Process Commander contains a rules engine, database, processing
logic, and functions — providing the base upon which Pegasystems Frameworks
are built. Process Commander Frameworks are layered, making use of
underlying technology instead of reinventing process flows (Figure 1-1).
Additional flows and rules are contained in the Framework layer and support
application-specific functions (such as contact management or customer
service). The rules you modify when extending the Framework are at the top
level, as they supersede the Framework defaults.
Figure 1-1. Process Commander Frameworks Showing Layers
Because Pegasystems Frameworks all share the same underlying technology,

configuration processes (such as creating accounts and copying rules) are
identical to those in Process Commander.
You can use the Framework RuleSets as a starting point for extending the
Framework, making it specific to your organizational needs.
Who Should Read This Document?

Before you install, deploy, and extend your Framework, it is assumed you have
attended the courses listed below for your specific user role. The specific user
roles addressed are the following:
■ Business Managers — responsible for evaluating the Framework solution

and possess a general, non-technical understanding of its features and
capabilities.
■ Project Managers / Business Analysts — responsible for implementing a

Framework solution that can be applied to specific business requirements,
and ensures compliance and continuous improvement across organizations.
■ System Architects / Application Developers — responsible for building,

maintaining, modifying, and extending the Framework.
■ System and Database Administrators — responsible for the installation,

security, and ongoing operational functions of the Framework such as
access, tuning, and troubleshooting. These users are presumed to be
experienced with system operations.
Education and Training

Pegasystems Educational Services delivers in-depth programs that are
designed, delivered, and taught by certified experts for those who would like
additional training. Through hands-on, role-based training, students receive
critical knowledge from professionals skilled in the implementation of
PegaRULES Process Commander solutions.
For more information about Pegasystems programs and schedules, visit us at

http://pega.com/Services/EducationalServices/Education.asp.
Other Information to Read

Process Commander and other framework documentation is available on the
Pega Developer Network (PDN), a section of the Pegasystems Support Network
located at pdn.pega.com. Technical notes, application help and configuration
how-tos and tips for using PegaRULES Process Commander are also available
on the PDN.
For information on installing or working with third-party applications, such as
Microsoft Visio, consult the vendor documentation.
Chapter 2
Deploying the Framework
This chapter describes how to set up the RuleSet, RuleSet version, and class
structure to begin deployment of the Framework and to build your application
while protecting the delivered Framework structure.
Note: For additional information about completing any of the forms, use
the PegaRULES Process Commander Application Developer Help and
the Pega Developer Network (PDN).
Documenting Your Application

Before you begin the deployment process, it is important to understand what
classes, rules, and flows already exist. All PegaRULES Process Commander
Frameworks include a self-documenting feature that enables you to develop
and document your application simultaneously, making it easy for any
developer to continue where you left off. Use the tools and reports described
below along with this document to deploy, understand what has been
delivered, and extend the Framework.
The Application menu provides access to information about your

application. You can use the following:
■ Preflight — to evaluate the flow rules, flow action rules, section rules
and activities against the design and implementation principles known as
SmartBuild guardrails.
■ Document Button — to produce a Microsoft Word document listing all

the rules associated with the selected application. Complete the pop up
dialog to control which rules are presented and which sections appear in
the document. You can choose:
− Which summary chapters to include:
• Application overview
• Work class hierarchy
• Process hierarchy and diagrams
− Which rules and versions; the section criteria includes:
• All rules
• Rules changed between identified dates
• Highest version for each rule
− Which detailed chapters to include:
• Decision logic
• Integration
• Rule inventory and update comments for each rule
The short description from the rule form appears with each rule listed.
Deploying the Framework 2-3
■ Inventory Button — to produce an interactive HTML report that lists all

the rules associated with the application sorted by the Applies To class.
You can click a rule name to open the rule.
The Flow Explorer is available from the Process Slice (Facility) on the
Developer Portal. It lets you display the starter flows and helps you to
understand the relationships among the flow rules in the selected application.
Starter flows (those that create new work objects) appear at the left of the
display. Subflows (called Branched To flows) are referenced by a Split-Join
or Split-forEach shape appear to the right. Lines connect the starter flows to
the subflows.
To begin:
1. Click the Process Slice icon.
2. Open one of the flow rules.
3. Click the related rules toolbar button.
4. Choose Flow Explorer for the flow. You can:
■ Check By Description? to view the short description text within the

rectangle for each flow rule or leave the box unchecked to display
the Flow Type key part.
■ Adjust the levels to determine how many levels are presented.
You can also select the View > Rules option to run several different rule
reports.
As you extend your Framework, complete the Full Description and Usage
fields on the History tab of each rule form. Enter information in these fields
that explains what the rule is for and how it is used. You can then create a list
view report that shows the information you entered for each rule.
Creating a New RuleSet

The RuleSet you create lets you tailor your Framework to suit your
production environment. RuleSets also provide security, version control, and
the ability to move your application to a different Process Commander
environment.
Give your RuleSet a name that helps you manage and identify its contents.
Your RuleSet name can be up to 255 characters long, must start with a letter,
and should contain only letters, and digits. Use names that are short and
easy to remember.
The first part of the name should represent your company and the second
part should represent the application content or purpose. For example, you
might use your company’s stock ticker symbol and then add something
representing the application purpose or its contents.
To create a new RuleSet:

1. Use the Class Explorer and select Rule- > RuleSet- > Name. A list of
RuleSets appears.
2. Click New. The New form appears. Complete and Save the New form.
The RuleSet form appears.
3. Complete the Security tab sections.
4. Go to the History tab and complete the Full Description and Usage
fields.
5. Save the RuleSet.

Creating a RuleSet Version

Each RuleSet has a version number that Process Commander uses (along
with other criteria) when determining the correct business rule to apply in
each situation as work is processed. Version numbers let you make changes
without impacting the existing version.
When you create a RuleSet, you must create the initial version number,
01-01-01, for that RuleSet. Use the required format of xx-yy-zz, where xx is
the major version, yy is the minor release within that version, and zz is the
interim, or update level within that release.
To create a RuleSet Version:

1. Use the Class Explorer and select Rule- > RuleSet- > Version.
The RuleSet Version form appears.
3. Complete the Security tab sections.
fields.
5. Save the RuleSet version.

Adding Your RuleSet to the Administrator’s Access Group

Before users can access a new RuleSet, you must give them access by
adding the RuleSet to each access group for the users who need it. Before
doing so, you must add your custom RuleSet to the administrator access
group (with which you logged in) so that you can work with the RuleSet and
continue configuring your application. (See Chapter 3, “What is Already Set
Up” for a list of the default access groups and users.)
To add your custom RuleSet to the administrator access group:

1. From the View menu, click Organization > Access Groups
2. Click the administrator access group for your application to display the
rule. Figure 2-1 shows an example using the PegaInsure access group.
The PegaInsurance application shown under Applications on the left
specifies the RuleSets that you need for the Insurance Industry
Framework.
Figure 2-1. Example Showing Administrator Access Groups
3. Insert a blank field at the top of the Production RuleSet list and enter
the name of your RuleSet.
fields.
5. Click Save. Log off and back in to access your RuleSet.

Creating Your Top-Level Class

Your application uses a hierarchical class structure to define work objects so
they can share common attributes and control rule resolution. A top-level
class is the starting place for your class structure.
For simplicity and clarity, use the same (or similar) names for the RuleSet
and its top-level class. In many cases, you may find it useful to define the
top-level class as the company name. For example, SampleCo- could be the
top-level class name for the company SampleCo.
Naming conventions:
■ Start names with a capital letter.
■ Names are case sensitive.
■ Alphanumeric characters are permitted.
■ Significant letters should be uppercase for legibility.
To create a top-level class:

1. Use the Class Explorer and select Rule- > Obj- > Class. A list of
classes appears.
The Class form appears.
3. Complete the Basic and History tabs. (Complete the Restrictions tab if
you want to limit which other objects can reference this class.)
4. Click Save.
Copying the Work Class Group to Your Class Hierarchy

Optionally, you might want to copy your work class group from your
Framework into your RuleSet to provide the data structure for various types
of work in your application. Many rules in your application reference the class
data structure.
Class groups are the link between your class structure and the underlying
database, and they must be unique across your organization (the application
prevents you from creating a duplicate).
The Clone a Class Group link in the Database section of the Administration
workspace starts the Direct Inheritance wizard. The wizard creates a new set
of classes (one of which corresponds to a class group) that matches the
classes below a specified class.
To copy a class group to your class hierarchy:

1. On the Tools menu, select Database > Clone Class Group.
2. The first Direct Inheritance Wizard screen appears.
3. Complete the fields and click Next. The second wizard screen (Class
Mapping) appears.
4. Change the RuleSet name to your custom RuleSet name so the rules
are created in your RuleSet.
5. Scroll down and click Next. The third screen appears and displays a list
of generated classes.
Copying the Data-Admin-DB Table Instances

Optionally, you can copy the Data-Admin-DB-Table instance from your
Framework to your class hierarchy to specify the correct database tables for
your new classes.
To copy the Data-Admin-DB-Table instances:
1. From the Rules By Type Explorer, select Data- > Admin- > DB- > Table
to display a list of tables.
2. Scroll down until you see the instance you want to copy.
3. Open the instance and click Save As. The Save As form appears.
4. Change the Class Name replacing what exists with your Class Name.
Click Save As to save the instance in your class. (You only need to
replace the XX portion of the name with your name.)
5. Change the Short Description to replace the ClassName with your

Class Name when appropriate and click the Save icon.
6. Repeat for each instance that you want to copy.
7. Repeat for the History-ClassName-Work instances.
8. Repeat for the Index-ClassName-WorkParty instances.

Setting Up Calendars
The calendar identifies business days and the hours of operation on these
days. Holidays and other non-work days, typically Saturday and Sunday, are
considered non-business days.
Calendars affect the following activities:
■ Case types that require a work date to be a business day
■ Service Level Rules that measure goal and deadline times in business
days
As part of the deployment process, you can add, delete, and update the
calendar to reflect your operation’s open business days and local holidays.
The RuleSet record is Data-Admin-Calendar. The default time zone is EST.
Figure 2-2 shows the 2007 calendar supplied with the product.
Figure 2-2. Default Calendar for 2007

Setting Up Correspondence
The Insurance Industry Framework comes with a few predefined
correspondence templates.
Some correspondence rules are called top-level rules (indicated on the

Prompts tab of the rule form). Master templates are based on a top-level
correspondence rule and can include other rules or references to other rules.
The correspondence type — whether e-mail, mail, phone, or fax — is defined
in the top-level correspondence rule when it is created.
The rules define various correspondence segments such as the header,

footer, and body. Each segment (or stream) provides a piece of the HTML
code needed to generate a complete piece of correspondence. The
advantage of defining correspondence templates in separate rules is that one
header or footer, for example, can be used in many correspondence rules.
Figure 2-3 shows a representative correspondence template structure.
Figure 2-3. Standard Correspondence Template Elements

Because the correspondence is HTML based, it provides the opportunity to

create a professional look and feel to letters, e-mails, and faxes that are sent
to customers and banks. See Chapter 3 What is Already Set Up for a list of
preconfigured correspondence templates and correspondence fragments.
E-mails are generated through capabilities built into PegaRULES Process

Commander. The routing, printing, and faxing of correspondence is handled
by an interface to the PegaDISTRIBUTION Manager. However, it is not
necessary to have PegaDISTRIBUTION Manager installed when updating
and testing changes to the templates. Correspondence will be generated,
attached to the case, and can be reviewed online in its printed form. It won’t
print until the interface is active.
Tip: To copy and customize the templates in your RuleSet, maintain the
same Correspondence Rule name to avoid unnecessary updates to
workflow elements that call specific templates. Add templates only when
no alternative is available.
Sample HTML and Template

Figure 2-4 shows and example of the underlying HTML for a
correspondence template that is used to notify a claimant via Email.
Figure 2-4. Correspondence Template —Decision Letter to Claimant via Email

Printing and Faxing

PegaDISTRIBUTION MANAGER is a required companion product that works
with the Insurance Industry Framework to activate printers and print servers
to send correspondence in print, fax, or Rich Text Format (RTF) file modes. It
can also print HTML files and their associated image files. Installed
independently of the framework, it is designed to run on Microsoft Windows
2000 Professional or Server or Windows XP.
To install and configure the PegaDISTRIBUTION MANAGER, refer to the

PegaDISTRIBUTION MANAGER (IOS) for PegaRULES Installation and
Configuration Guide.
Setup Requirements Before Extending

Ensure you have set up the following before extending your Framework:
Operators — Operator IDs define the type of users who work with the
Framework and the application you build. Your Framework comes with a set
of predefined operator IDs that you can use to create your own.
Access Groups — Operators IDs specify an access group that determines

options that portal users see, RuleSets they can access, classes of work that
appear in their portal, default class group of rules that users work with, and
access roles. Your Framework comes with a set of predefined access groups
that you can use to create your own.
Access Roles — An access role is defined as having certain class access

rights. Users can have one or more access roles, which are listed in access
groups.Your Framework comes with a set of predefined access roles that
you can use to create your own.
Privileges — A privilege allows users with a particular role to execute certain

functions. Privileges are associated with access roles, not directly with users.
If a user has the access role with which the privilege is associated, the user
has the privilege. Privileges also play a role in routing work as users can only
receive work items for which they have privileges. Configuration of these
rules should happen on site to guarantee that the system behaves in a
manner consistent with desired business practices.
Tip: Access-Role-Obj rules (of type Rule-Access-Role-Obj) associate

access roles with the classes to which they provide access and with any
relevant privileges or access settings. When you create a new access
role, you must associate it with the appropriate classes.
When you associate an access role or privilege with a class, you not only
associate the names of the rules, but you also specify the level of access
a role or privilege has to a class or the conditions under which the role or
privilege can access the class. This process allows for an extremely
flexible and powerful way of defining class-based security.
Chapter 3
What Is Already Set Up
This chapter describes defaults and samples that are set up and ready for your
use. It is expected that you will use these as a basis for extending the Insurance
Foundation Framework. The topics include:
■ System Administrator Account
■ RuleSet Hierarchy
■ Data Classes
■ Work Object Naming Conventions
■ Default Work Groups and Workbaskets
■ Default Operators and Access Groups
■ Predefined Access Roles and Privileges
■ Predefined Work Parties
■ Correspondence Templates
■ Sample Data for Testing Purposes
■ Party Search
System Administrator Account

The Framework uses the following Operator ID as the default system
administrator account. You should change this password after logging in.
Note: Operator IDs are not case sensitive, but passwords are case sensitive.
This Operator ID gives you access to all the insurance functions.

Operator ID: Administrator@insco.com
Password: install
What Is Already Set Up 3-3
RuleSet Hierarchy
RuleSets are arranged hierarchically, with the more general rules at the bottom
and more specific rules at the top. The four RuleSets at the bottom are standard
in all applications and control the underlying Process Commander operations,
while the rules towards the top control application functions. The RuleSet order is
critical to rule resolution. To find the appropriate rule, Process Commander
begins with the top RuleSet in this list, and if the rule is not found moves to the
next RuleSet. In this manner, custom, site-specific rules have precedence over
application-specific rules. Figure 3-1 shows the RuleSet hierarchy with all the
Framework layers.
Figure 3-1. RuleSet Hierarchy
The Framework RuleSets include:

■ MyInsCo — contains the rules that implement examples or certain industry
use cases. These rules leverage PegaInsure, but will likely be overwritten.
■ PegaInsure— contains the insurance functional components with definitions
that inherit from or override those found in the Piif layer. The top-level class
is named PegaIns-.
■ PegaApp – contains rules that are common to all frameworks. Used by the
Framework to take advantage of the external database tables and the rules
to support them. The top-level class is named PegaApp-.
■ Piif — contains the data structures and properties defined in the IBM
Insurance Application Architecture and used to define entities, products, and
components. The top-level class is named Piif-.
■ PegaSP — contains the rules for creating a new product by configuring
components, features, pricing, eligibility, validation, and display of the
objects. The top-level class is named PegaSP.
The Process Commander RuleSets include:

■ Pega-AppDefinition — contains the rules for the set of application
development tools and wizards designed to capture and tie business and
project goals, objectives, and use case requirements to action
implementations
■ Pega-ProCom — workflow support and portal facilities
■ Pega-IntSvcs — system interface support, including connectors and services
■ Pega-WB — internal logic and facilities
■ Pega-RULES — activities, Java generation, rule resolution, and other basic
rules engine operations
Class Structure
When developing class and property definitions for your applications, create a
RuleSet that inherits from the PegaInsure RuleSet. Use class names that do not
include “Pega” as a prefix thereby preserving the namespace integrity of created
rules. Because different systems have different requirements, the Framework’s
Piif classes and properties are configured as generically as possible. It is
expected that they will be overridden at a higher level RuleSet when appropriate.
Class Inheritance
This section describes how properties are inherited in the Framework.
The primary examples in inheritance, however, involve the definition of

Agreements (Policies) and their components. Policies are defined within the
PegaIns-Data-InsurancePolicy- class tree. Policy components are defined within
the PegaIns-Data-PolCmp- class tree.
Parties are defined in the PegaIns-Data-Party- class and inherit from Data-Party.
Figure-3-2 lists some of the predefined component classes in the PegaInsure-

Data-PolCmp- class that are available for your use. These are models that you
can follow by copying them into your own RuleSet. Use the Class Explorer to
view a complete list of the classes defined in within the Framework.
Component Used to Represent

InsuredVehicle Vehicles in an auto policy
NamedDriver Drivers in an auto policy
AutoCoverage Specific auto coverage options

and features
InsuredPropertyLocation Locations in a BOP Policy
InsuredBuilding Buildings in a BOP Policy
InsuredItem Specified items in a BOP policy
Liability General liability in a BOP policy
InsuredRisk Specific Risk options and features
InsuredLife Life insurance coverage
Figure-3-2. Predefined Policy Component Classes

Class Structure for Work Objects

Work object types defined in the Framework are:
■ Application (new business)
■ Change Policy
The class structure to support these work types may have Line Of Business
specific variants as shown below.
Extension Tip The structure is intentionally incomplete as it is assumed you

will expand for your site.
PegaIns-Work-
PegaIns-Work-Application
PegaIns-Work-Application-Com-
PegaIns-Work-Application-Com-Automotive
PegaIns-Work-Application-Com-BOP
PegaIns-Work-Application-Indiv-
PegaIns-Work-Application-Indiv-TermLife
PegaIns-Work-Application-Indiv-VarUnivLife
PegaIns-Work-Application–Indiv-WholeLife
PegaIns-Work-Application-Pers-
PegaIns-Work-Application-Pers-Automotive
PegaIns-Work-Application-Pers-Household
PegaIns-Work-ChgPolicy
PegaIns-Work-ChgPolicy-Com-
PegaIns-Work-ChgPolicy-Indiv-
PegaIns-Work-ChgPolicy-Pers-
PegaIns-Work-ChgPolicy-Pers-Automotive
Data Classes
Data classes define the data structures for supporting information that the
Framework uses to process work. The data classes used in the Framework are
listed below.
The data classes that represent different types of policies are:

■ PegaIns-Data-InsurancePolicy-Commercial-Auto
■ PegaIns-Data-InsurancePolicy-Commercial-BOP
■ PegaIns-Data-InsurancePolicy-Individual-TermLife
■ PegaIns-Data-InsurancePolicy-Individual-VarUnivLife
■ PegaIns-Data-InsurancePolicy-Individual-WholeLife
■ PegaIns-Data-InsurancePolicy-Personal-Automotive
■ PegaIns-Data-InsurancePolicy-Personal-Household
The data classes that represent components used in defining a policy are:
■ PegaIns-Data-PolCmp-
– and its subclasses for policy components
The data classes that represent parties involved in an insurance agreement are:
■ PegaIns-Data-Party-Person
■ PegaIns-Data-Party-Person-Agent
■ PegaIns-Data-Party-Org-
■ PegaIns-Data-Party-Org-Company
■ PegaIns-Data-Party-Org-Agency
Interface Classes
The Insurance Industry Framework uses external database tables to store its
data instances for an insurance policy. It uses a simplified data model to
represent insurance policies. It also uses the same data model that PegaApp
uses to represent a contact, storing the contact information in various database
tables, such as the PA_CONTACT and PA_ADDRESS tables among others. The
remaining policy information is stored in the IIF_POLICY, IIF_POLICY_LINK and
IIF_AGENCY_LOB tables. More detailed information on these tables can be
found in Chapter 6: Integrating with External Systems.
The Interface classes described below are the concrete data classes used to
persist insurance policy data.
PegaIns-Interface-InsurancePolicy
This class Inherits from PegaApp-Interface. PegaApp does not have an
InsurancePolicy class to inherit from. Consideration was given to inherit from the
PegaApp’s Account class, but an account and insurance policy have enough
differences to warrant two different classes, The InsurancePolicy class does not
inherit from Account. This gives the ability for the expansion of the IIF to use the
PegaApp-Interface-Account class in the future.
PegaIns-Interface-PolicyLink
This class inherits from PegaApp-Interface. Similar to the Policy class, PegaApp
does not have a PolicyLink class to inherit from. The PolicyLink class contains
information that links the policies with contacts via roles. It also contains
information to facilitate policy searches.
PegaIns-Interface-AgencyLOB
This class represents the Agency LOB data. It contains sample data for each
agencies Line Of Business. An Agency is stored in the BusinessUnit table. Each
instance in this class represents a line of business that an agency is licensed to
sell in a given state, and specified period of time. It is linked to the agency by the
AgencyCode.
PegaIns-Interface-Contact
This class inherits from PegaApp-Interface-Contact. It contains sample contact
data used in the Framework.
PegaIns-Interface-Roles
Inherits from PegaApp-Interface-Roles. It contains sample role data used in the
Framework, such as Applicant and InsuredParty.
Data-Admin-DB-Table
Each of the interface classes mentioned above have associated instances in the
Data-Admin-DB-Table class to identify the database information for the
associated table. More information about these database tables can be found in
Chapter 6: Integrating with External Systems. The following table lists the
interface classes and their instances in the Data-Admin-DB-Table class.
Class Database Table Database Name

PegaIns-Interface-InsurancePolicy IIF_POLICY Sample
PegaIns-Interface-PolicyLink IIF_POLICY_LINK Sample
PegaIns-Interface-AgencyLOB IIF_AGENCYLOB Sample
PegaIns-Interface-Contact PA_CONTACT Sample
PegaIns-Interface-Roles PA_ROLES Sample
Figure 3-3. Data-Admin-DB-Table Interface Instances

Work Object Naming Conventions

There are three primary types of work objects: basic work objects, covers, and
folders. Applications use basic work objects; some, but not all, may use covers or
folders.
■ Work objects capture and process information about an individual unit of

work.
■ Covers tightly coordinate processing of one or more distinct, but closely

related, work objects. The system normally resolves a cover work object after
all its component work objects are resolved.
■ Folders are not currently used.
When your application initiates a work object, a predefined model populates key
property values (such as urgency) that directly affect the work object’s relative
priority and placement in operator worklists. As work objects progress towards
resolution, core property values such as priority and status are continually
updated to reflect the current stage of processing. In the case of Insurance
Applications for new business, models are applied to all the embedded
components in the product definitions before the data entry screens are
generated.
Each work object has a unique ID that is computed by combining a system-

assigned number and a prefix defined in a pyDefault Model rule. You can change
the prefix or create additional prefixes by copying the Rule-Obj-Model called
pyDefault in the Work- class into your RuleSet changing its class to apply to your
own installation specific class structure, and making your changes.
Work objects created by this Framework use the default W- prefix.

Default Work Groups and Workbaskets

Figure 3-4 lists the default workbaskets used in the Framework. The work group
is named MyInsCo-NewBusiness.
Workbasket Description
UnderwriterQueue Policy applications waiting for underwriting specific assignments
NewBusinessErrors Policy applications created from a message that have errors in

processing
PartialApplications Policy applications that have data entry in progress
Figure 3-4. Default Workbaskets

Default Operators and Access Groups

The Framework comes with sample operators and access groups (Figure 3-5).
All passwords are set to install.
Operator ID Access Group Portal Name

Broker@insco.com PegaInsureWorkUser WorkUser
UnderWriter@insco.com PegaInsureUnderwriter WorkUser
Administrator@insco.com PegaInsure DeveloperSP
TSmith@TomsInsAgency PegaInsureWorkUser WorkUser
PegaInsureWorkManager IIFWorkManager
PegaInsureACORD DeveloperSP
Figure 3-5. Insurance Industry Framework Operators and Access Groups

Predefined Access Roles and Privileges

Your Framework includes a set of predefined access roles. These roles are
defined as Rule-Access-Role-Name instances and are associated with an
operator’s access group. Each of these roles has a corresponding rule in Rule-
Access-Role-Obj where you can define specific privileges for each of these roles.
In the Framework, Rule-Access-Role-Obj instances have been added for

WorkMgr4 and User4 giving them Read-Write access to the PegaIns-Data-
InsurancePolicy database table.
Predefined Work Parties

The Framework defines work parties in a record called Rule-Obj-Workparty for
the PegaIns-Work- types and references the following party roles:
■ Applicant
■ Broker
■ Originator
■ Underwriter
■ Beneficiary
■ AuthorizedParty
■ Interested
■ Agent
Note: When the product is commercial, the party classes are defined to
reflect that difference, and are changed to -party-org instead of
-party-person.
Correspondence Templates
The Framework comes with a number of sample correspondence templates and
fragments. Templates are defined as instances of Rule-Obj-Corr. Fragments are
defined as instances of Rule-Corr-Fragment and are used in compiling
correspondence templates. Figure 3-6 and Figure 3-7 list the templates that
come with Process Commander and the Framework.
Process Commander Templates

Figure 3-6 lists templates that are not used in the Framework workflows but are
part of Process Commander and are available for your use. If you decide to use
any of these templates, remember that they are samples, and you will need to
copy them to your RuleSet to modify them to meet your requirements.
Template Type Purpose

AcknowledgeSample Email, Fax, Mail, PhoneText Internal acknowledgement of a work object
DeadlineTimeReminder Email Notification that a work object has passed its
deadline
Details Email, Fax, Mail Details of a work object
ExternalAcknowledgeSample Email External acknowledgement of a work object
ExternalRequest Email Request for information about a work object
assigned to an external user
ExternalRequestBrief Email Assignment of a work object to an external user
ExternalSample Email Correspondence with external party regarding a
work object
Footer Email, Fax, Mail Signature for correspondence
GoalTimeReminder Email Notification that a work object has passed its
goal time
Header Email, fax, mail Salutation for correspondence
LateTimeReminder Email Notification that a work object is late
NewAssignment Email Notification of a new assignment on a worklist
NotifyReopen Email Notification that a work object has been
reopened
PromptSample Email, Fax, Mail, PhoneText Prompt for user input
QuestionAboutItem Email, Fax, Mail, PhoneText Request for more information about a work
object
ResolutionDetails Email, Fax, Mail Resolution details for a work object
ResolutionSample Email, Fax, Mail, PhoneText Notification that a work object has been resolved
Figure 3-6. Process Commander Correspondence Templates
Framework Templates
Figure 3-7 lists templates that are used in the Framework workflows. These are
samples and if you decide to use any of these templates, copy them to your
RuleSet to modify them to meet your requirements.
Template Type Purpose

NewPolicy Email Acknowledge creation of the new policy
PolicyBinder Email The binder for the new policy
ExternalRequest Email External request to adjusters
Figure 3-7. Framework Correspondence Templates

Sample Data to Test Use Cases

Sample data is provided for testing purposes. The Framework uses sample data
to represent its party data. This sample party,or contact,data is stored in external
database tables provided by the PegaApp layer. The Framework also provides
sample data for policies and endorsements to those policies (policy transactions)
which is also stored in external database tables. Figure 3-8 lists the tables that
contain sample data used by the Framework. For a complete list of all database
tables shipped with the Framework, see Appendix A: Database Tables.
Table Name Description

IIF_POLICY Primary table to store insurance policy information
IIF_POLICY_LINK Stores relationships between insurance policies,

contacts and the roles the contacts have in the
policy
IIF_AGENCYLOB Stores Agency Line Of Business information
PA_ROLES Stores role information for policy, contact and

business unit associations
PA_CONTACT Primary table to store information about contacts,

including agents
PA_ADDRESS Stores address information about contacts and

business units
PA_COMMUNICATION_OPTIONS Stores communication information about contacts

and business units
PA_BUSINESS_UNIT Stores information about business units, including

agencies
PA_CONTACT_BUSINESUNIT_LINK Stores relationships between a contact and a

business unit
PA_BUSINESSUNIT_LINK Stores relationships between business units, ie a

Master Agent and its Agencies
Figure 3-8. Framework Sample Data Tables

Contact Search
The contact search functionality is implemented in the Framework using the
searching capability provided in the PegaApp software layer. The rules provided
in PegaApp that implement contact searching have been extended and modified
to fit the specific Framework requirements For more information on these rules
see Chapter 6: Integrating With External Systems. Figure 3-9 lists the rules
involved in executing a contact search. This table is followed by processing
details for the key rules in the search process.
RuleType Class Rule Description
Flow PegaIns-Work IIFAppContactSearch Flow to handle contact search functionality

specific to the Framework
FlowAction PegaApp-Work- AppFindContact Enter search criteria and execute search
Flow PegaApp-Work- AppGetContact Handles list of contacts resulting from search
FlowAction PegaApp-Work- AppSelectContact Selects a contact from the list provided
FlowAction PegaApp-Work- AppFindBusinessUnit Enter search criteria and execute search
Flow PegaIns-Work- AppGetBusinessUnit Handles list of business units from search
Activity PegaIns-Work IIFAppGetContactDetails Gets contact details for selected contact
Activity PegaApp-Work- AppReadContactInfo Reads contact information
Activity PegaApp-Work- AppListAddressesForContact Gets addresses for contact
Activity PegaApp-Work- AppCommOptionsForContact Gets communications options for contact
Activity PegaApp-Work- AppGetContactBUAssociations Gets associations between contacts and

business units
Activity PegaIns-Work IIFCreateContactParty Creates the appropriate pyWorkParty page in

the work object
Activity PegaIns-Work IIFMapPartyDetails Maps data from the contact search data into
the work object
Activity PegaIns-Work IIFAppGetBusinessUnitDetails Gets business unit details for selected item
Activity PegaApp-Work- AppReadBusinessUnitInfo Gets business unit info from database
Activity PegaIns-Work IIFCreateBusinessUnitParty Creates the appropriate pyWorkParty page in

the work object
Activity PegaIns-Work IIFMapBusinessUnitPartyDetail Maps data from the business unit search data
s into the work object
Figure 3-9. Contact Search Rules

PegaIns-Work.IIFAppContactSearch Flow
This flow handles searching for both a business unit and a person contact. It
accepts two parameters:
■ BUSearch – True if this should search for a BusinessUnit. This is set to True
in the Commercial product NB flows. All other flows do not set this
parameter. The default value is False.
■ PartyRole, Specifies the role that this contact is being searched for. This
PartyRole parameter signifies the role that this contact has in the insurance
policy, ie, InsuredParty, Claimant, etc. It is used to map the contact data into
the correct pyWorkParty page group for this role.
This flow:
– Uses the PegaApp-Work.AppFindContact flow action to enter the search
criteria and present a list of contacts that fit the search criteria
– When one contact is selected, it calls the IIFAppGetContactDetails
activity to retrieve the contact data
– Then, exits
PegaApp-Work. AppFindContact Flow Action

This flow action:
– Executes PegaApp-Work.AppFindContact HTML to set up the display for
entering search criteria
– Calls the post activity PegaIns-Work.AppFindContact to validate and
setup search criteria
PegaApp-Work-. AppGetContact Flow

This flow:
– Calls the AppSelectContact flow action to handle the contact search.
– Calls the AppAddContactStart flow action,that calls the
AppAddContactFromSearch flow to handle adding a new contact
PegaApp-Work-. AppSelectContact Flow Action

This flow action calls PreActivity PegaApp-Work-.AppCallAppReadContactList
which calls PegaApp-Interface-Contact.AppReadContactList that executes the
SQL that generates the list of contacts
PegaIns-Work.IIFAppGetContactDetails Activity
This activity:
– Uses an input parameter of Role Name and executes a number of steps
to gather the details for the contact that was selected from the list of
contacts.
– Uses activities provided with PegaApp to retrieve the contact data from
the various database tables and reconstitute the data into the PegaIns-
Interface-Contact class
– Calls IIFCreateContactParty to create the work party
PegaIns-Work.IIFCreateContactParty Activity
This activity:
– Creates the pyWorkParty instance using the RoleName input parameter
as the value of the PageGroup index
– Calls IIFMapPartyDetails to map the data from the selected Contact into
the work object
PegaIns-Work.IIFAppGetBusinessUnitDetails Activity
This activity:
– Uses an input parameter of Role Name and executes a number of steps
to gather the details for the business unit that was selected from the
previously displayed list of business units
– Uses activities provided with PegaApp to retrieve the business unit data
from the various database tables
– Calls IIFCreateBusinessUnitParty to create the work party
PegaIns-Work.IIFCreateBusinessUnitParty Activity
This activity:
– Creates the pyWorkParty instance using the RoleName input parameter
as the value of the PageGroup index
– Calls IIFMapBusinessUnitPartyDetails to map the data from the selected
BusinessUnit into the work object
PegaIns-Work.IIFMapPartyDetails Activity
This activity maps data from the AppContact page on the clipboard that was
populated by the PegaApp contact search rules to the pyWorkParty page
specified by the input parameter, RoleName.
Policy Search
The Framework provides the ability to search for policies in a number of different
ways. Policies can be searched by:
■ Contact
■ Contact and Role
■ Contact, Effective Date, and Policy Type
■ PolicyID – exact match of PolicyID
■ PolicyID – listing all policy transactions
These searches are described on the following pages which also include details
about how they are implemented in the Framework.
Policy Search Implementation

Since the user will select a policy from a list of policies, policy searches are
implemented by using a Selectable ListView.
Setting Up Selectable ListViews

The following steps describe how to set up a Selectable ListView.
1. Policy searches are initiated from a flow action that specifies an HTML-
Section to display on the HTML tab.
2. On the HTML tab of the Section, include a JSP tag that references a
ListView that is configured as a Selectable ListView
3. In addition to using the standard configuration for a list view, the following
Framework configuration was implemented to configure the ListView as a
‘selectable’ list view:
On the Fields tab, check the ‘Embedded’ box
On the Content tab:

– Specify the properties to be returned
– Specify “Key Of A Row” as pzInsKey
– In the Report Source area:
• Specify a custom getContent activity in the Activity Name field
• Specify the clipboard page for the results in the Content Page
Name field
On the Selectable tab:

– Check the “Enable Selection of Rows” box
For framework purposes the options are set as:
■ Mode: Single Select
■ Copy To: Page
■ Name: pyWorkPage – specifying the properties for the selected policy you
want to put on the clipboard for reference later
4. Create a custom getContent activity in the Embed-ListParams class to

create the list of policies. A custom activity is needed here because the
search needs to be executed against the IIF_POLICY_LINK table and the
underlying SQL includes a join between two database tables.
5. Create the SQL needed to execute the desired search.
Extension Tip: For details about setting up a List View and more information
about the use and configuration of Selectable List Views, see Application
Developer Help or the PDN.
Search Types and Implementation Rules
Policy Search By Policyholder

The policy search by policyholder lists all policies for a given policyholder. For
example, if Peter Roberts has an Auto Insurance Policy and two Life Insurance
Policies, three policies will appear in the list. This search is currently being used
in the ChgPolicy flow to display the list of policies for a given policyholder, where
one will be selected to be processed by the flow. If the policyholder is a
BusinessUnit (for Commercial Lines), then the search filters the list of policies
further by the AuthorizedParty for the BusinessUnit. Figure 3-10 lists the rules
used to implement a selectable list view for this search type followed by specific
implementation details for each rule in the list.
Rule Class Rule Description

Type
Flow PegaIns-Work- InsPickPolicy Flow action to display list
Action ChgPolicy of policies
HTML- PegaIns-Work PolicyListForPolicyholder Defines HTML used to

Section display list of policies
ListView PegaIns- ListPoliciesForPolicyholder Selectable list view to

Interface- display list of policies and
InsurancePolicy allows one to be selected
Activity Embed- getContentPoliciesForPolicyholder Executes an RDB-List to

ListParams run SQL to retrieve
policies
Connect- PegaIns- IIFGetPolicyListForPolicyholder SQL to get policies from

SQL Interface- db table.
InsurancePolicy
Connect- PegaIns- IIFGetPolicyListForPolicyholderAndA SQL to get policies from

SQL Interface- uthorizedParty db table.
InsurancePolicy
Figure 3-10. Policy Search by Policyholder Rules
PegaIns-Work-ChgPolicy.InsPickPolicy FlowAction
On the HTML tab of the flow action, reference the HTML-Section named
PolicyListForPolicyholder.
PegaIns-Work.PolicyListForPolicyholder HTML-Section
This Section is in the PegaIns-Work class making it available for all work types.
On the HTML tab of this section, include directives to execute a list view as
follows:
<pega:listView name="ListPoliciesForPolicyholder" className="PegaIns-

Interface-InsurancePolicy" header="false" />
PegaIns-Interface-InsurancePolicy.ListPoliciesForPolicyholder ListView
Specify a custom getContent activity, getContentPoliciesForPolicyholder, to get
the list of policies from the Policy and PolicyLink tables.
Embed-ListParams.getContentPoliciesForPolicyholder Activity
This activity sets .PartyID on QueryParams page for the SQL statement to use as
search criteria. It then executes an RDB-List to call depending on whether the
policyholder has a party type of ‘B’ (BusinessUnit) or ‘C’ (Contact). If it is a ‘C’ it
executes the IIFGetPolicyListForPolicyholder SQL, Otherwise, it executes the
IIFGetPolicyListForPolicyholderAndAuthorizedParty SQL.
PegaIns-Interface-InsurancePolicy.IIFGetPolicyListForPolicyholder
Connect-SQL
This SQL rule currently only exists for an Oracle database. It executes a SQL
statement to return information for a list of policies for the PartyID specified on
the QueryParams page on the clipboard. If more than one policy transaction
exists for any given policy, the latest transaction is returned.
PegaIns-Interface-
InsurancePolicy.IIFGetPolicyListForPolicyholderAndAuthorizedParty
Connect-SQL
This SQL rule only exists for an Oracle database. It executes a SQL statement to
return information for a list of policies for the PartyID and AuthorizedParty
specified on the QueryParams page on the clipboard. If more than one policy
transaction exists for any given policy, the latest transaction is returned.
Policy Search By Policyholder, Effective Date and Policy Type

The policy search by policyholder, effective date and policy type lists all policies
for a given policyholder and policy type where the search date falls between the
TransactionEffectiveDate and TransactionEndDate. This search currently is not
used in the framework. It is provided as functionality that can be used or
extended in your implementation. Figure 3-11 lists the rules used to implement a
selectable list view for this search type followed by specific implementation
details for each rule in the list.
Rule Type Class Rule Description

HTML-Section PegaIns-Work PolicyListForPolicyholder_Date_ Defines HTML
Type used to display list
of policies
ListView PegaIns- ListPoliciesForPolicyholder_Date_ Selectable list view
Interface- PolicyType to display list of
InsurancePolicy policies and allows
one to be selected
Activity Embed- getContentPoliciesForPolicyholder_ Executes an RDB-

ListParams Date_PolicyType List to run SQL to
retrieve policies
Connect-SQL PegaIns- IIFGetPolicyListForPolicyholder_ SQL to get policies

Interface- Date_PolicyType from db table
InsurancePolicy
Figure 3-11. Policy Search By Policyholder-Effective Date and Policy Type Rules
PegaIns-Work.PolicyListForPolicyholder HTML-Section
This Section is in the PegaIns-Work class so it is available for all work types. It
should be called from the flow action that you set up to execute this search. On
the HTML tab of this section, include directives to execute a list view as follows:
<pega:listView name="ListPoliciesForPolicyholder_Date_PolicyType"
className="PegaIns-Interface-InsurancePolicy" header="false" />
PegaIns-Interface-
InsurancePolicy.ListPoliciesForPolicyholder_Date_PolicyType ListView
This rule specifies a custom getContent activity,
getContentPoliciesForPolicyholder_Date_PolicyType, to get the list of policies
from the Policy and PolicyLink tables.
Embed-ListParams.getContentPoliciesForPolicyholder_Date_PolicyType
Activity
This activity sets .PartyID on QueryParams page for the SQL to use as search
criteria. It then executes an RDB-List to call the
IIFGetPolicyListForPolicyholder_Date_PolicyType SQL.
PegaIns-Interface-
InsurancePolicy.IIFGetPolicyListForPolicyholder_Date_PolicyType
Connect-SQL
This SQL rule currently only exists for an Oracle database. It executes a SQL
statement to return information for a list of policies that meet the search criteria
specified in the PartyID, PolicyType, and SearchDate properties on the
QueryParams page of the clipboard.
Policy Search by Contact and Role Type

This search lists all policies where a given contact has any role. It can be found
in the Data Reports section of the Monitor Activity screen. It is generated by the
ListView rule PegaIns-Interface-Contact-PolicyRoleSummary
.ListPoliciesByContactAndRole.
Policy Search by PolicyID

This search is executed in the ChgPolicy flow to find the policy directly by the
policy id instead of going through the contact search and choose a policy from
the list of policies presented. It provides the ability to find the policy by an exact
match on the policy id. It is initiated by the FindPolicyByID flow action that is
defined in the IIFAppContactSearchFlow. Figure 3-12 lists the rules used to
implement the Policy Search by ID functionality.
Rule Type Class Rule Description

Flow Action PegaIns-Work FindPolicyByID Flow action to enter PolicyID
Flow PegaIns-Work FindPolicyByID Controls process of policy
search by policy id
Activity PegaIns-Work GetCurrentPolicyKeys Reads the database to get
the keys for the last
transaction for this policy
Flow Action PegaIns-Work PolicyNotFound Handles Policy not found,
search again
Figure 3-12. Policy search by Policy Id rules
PegaIns-Work.FindPolicyByID FlowAction
This flow action is called from the IIFAppContactSearch flow. It displays a field to
enter the policy id which is used in the subsequent flow to get the policy.
PegaIns-Work.FindPolicyByID Flow
This flow first calls the activity, GetCurrentPolicyKeys, to retrieve the policy keys
for the latest transaction for this policy id. If the policy id is not found, it displays
the PolicyNotFound flow action. If the policy id is found, it returns to the calling
flow for continued processing. The actual retrieval of the policy data happens in
the SelectPolicy flow, using the keys determined in this flow.
PegaIns-Work.GetCurrentPolicyKeys Activity
This activity executes an RDB-List calling the GetLatestPolicy Rule-Connect-SQL

rule to get the keys for the last transaction for this policy in the IIF_POLICY table.
The keys it returns are PolicyID, ModNumber, TransactionEffectiveDate,
TransactionProcessDate.
PegaIns-Work.PolicyNotFound FlowAction
Displays that the policy is not found and allows the user to search again.
Policy Transaction Search Type

This search lists all transactions for a given PolicyID. It can be found in the Data
Reports section of the Monitor Activity screen. It is generated by the ListView rule
PegaIns-Interface-PolicyLink.ListPolicyTransactions.
Chapter 4
Extending the Framework
This chapter contains information to help you understand, extend and work
with the following components of the Framework:
■ Work Classes
■ Data Classes
■ Interface Classes
■ Work Objects
■ Agencies and Agents
■ Matching of Drivers and Vehicles

Extending the Work Class Structure

This section describes the work class structure shipped with the Framework
and how it can be extended to meet your organization’s requirements. Figure
4-1 shows the work class structure as it exists when the Framework is
installed.
Figure 4-1. Industry Framework Work Class Structure

Extending the Framework 4-3
Inheriting from the PegaIns-Work- class

The Framework’s PegaIns-Work class hierarchy inherits from Work- through
the PegaSP-Work- and PegaApp-Work classes. This structure is designed to
provide access to both Product Configurator and PegaApp rules and
functionality. The PegaIns-Work class hierarchy is organized by three work
type classes:
■ PegaIns-Work-Application
− Supports NewBusiness (NB) and Quote processing
− Contains the rules that are common to all types of Application (or NB)
processing. Most of the flows and subflows are found in this class with a
few of them extended into a lower class for modified processing
■ PegaIns-Work-ChgPolicy
− Supports Endorsement processing
− Contains the rules that are common to all types of policy change
processing
Within each work type class, there are subclasses for the following lines of
business. Figure 4-2 shows the structure in the Class Explorer.
■ Com- — Commercial lines
■ Indiv- — Individual lines
■ Pers- — Personal lines

Figure 4-2. Work Class Subclasses in Class Explorer
Within each class for a line of business, there are subclasses for product
groups such as Automotive, BOP (Business Owners Policy), and TermLife.
These subclasses can be specialized further to provide support for additional
subtypes of these product groups. In the Framework, these product groups
are associated with the product groups defined in the Product Configurator
Framework. Figure 4-3 shows the lines of business structure in the Class
Explorer.
Figure 4-3. Lines of Business Subclass Structure in Class Explorer
By setting up your class structure in a similar way and inheriting from the
PegaIns-Work class hierarchy, you have the start of a framework that can be
used to build out the class structure that meets your requirements. In
addition, you have access to all the rules provided in the framework that
support basic Insurance Processes.
Extension Tip: When extending the work class, you should clone the
class defining the work pool, PegaIns-Work, using the standard Process
Commander Clone a Class Group wizard. Do not make changes to the
PegaIns-Work class structure or rules. Instead, extend and override them
in your own class structure.
An example of an extended work class structure for New Business

processing with a Retail Store type of Business Owners Policy is shown in
Figure 4-4.
Figure 4-4. Example of Extended New Business Work Structure
Creating New Work Flows

In the Framework, NewWork flows exist in the subclass for the particular
product group, for example: Business Owners or Homeowners. This provides
the option to create a work object for each product group that appears in the
Process gadget of the Run menu. If you set up subclasses to specialize the
Product Group (for example: adding RetailStore) you can change the work
object class to the lower subclass once you have created the work object at
the product group class.
Integrating with Systems of Record and Policy Administration systems

When the Framework is deployed, the insurance policy information is stored
external to Process Commander either in database tables or in other external
systems of record. There are a number of integration rules that need to be
extended and modified to access these systems appropriately. For more
information about integrating with other systems, see Chapter 6: Integrating
with External Systems.
Extending the Data Class Structure

This section describes the data class structure shipped with the Framework
and how it should be extended to meet your organization’s requirements.
Figure 4-5 shows the data structure as it exists when the Framework is
installed.
Figure 4-5 Insurance Industry Framework Data Class Structure

Inheriting from the PegaIns-Data- Class Structure
The PegaIns-Data- class structure is set up to inherit from the Piif class
structure to provide access to the many properties provided in Piif.
The Piif class, and its children provide the foundation data structures of the
Framework. Piif contains over 550 classes, and over 2,000 properties that
can be used to represent the data aspects of insurance products,
agreements, and life-cycle processing.
The structure is based on the Interface Design Model of the IBM Insurance
Application Architecture (IAA) version 2006TR with one exception — the
Framework also leverages Process Commander’s extensive Party classes
and associated rules. The Process Commander party classes are
subclassed, with each new class directly inheriting from their Piif equivalent.
This provides direct access to both Process Commander and Piif party
properties.
As you customize the Framework to meet the needs of your own

environment, you can leverage the Piif class by having your data classes
directly inherit from the corresponding Piif class and then making
customizations as necessary to meet your business need.
The structure also can inherit from the PegaIns-Data-PolCmp classes. These
classes provide many of the common elements required to create Products
and their associated Policies. The PegaIns-Data-PolCmp classes typically
aggregate multiple Piif classes to provide more generic objects than using
Piif alone.
The PegaIns- class structures provide data classes for the following:
■ InsurancePolicy
− Class that represents a general insurance policy. It is specialized by its
subclasses.
− Contains subclasses that represent lines of business and product groups
similar to the class structure in PegaIns-Work-.
■ PolCmp
− Contains a number of subclasses that represent components in a
product. These classes are used when defining product and component
rules in the Product Configurator Framework. Subclasses defined here
inherit from the Piif class structure to take advantage of the many
Insurance properties provided by IAA – IBM’s Insurance Application
Architecture.
■ Party
− Contains classes that define parties used in the IIF
Figure 4-6 shows an example of inheritance from the PegaIns-Data-

InsurancePolicy class hierarchy.
Figure 4-6. Example of Extended Data Class Structure
Underwriting rules
Figure 4-7 shows an example of inheritance from the PegaIns-Data-PolCmp
class. In this example, the component subclasses are subclassed further to
provide additional specialization. The PolCmp classes contain many of the
underwriting rules. In the case where the underwriting rules are common to
the lines of business, the additional subclass specialization allows for this.
For example, the AutoCoverage rules may be different between Commercial
Auto and Personal Auto. In this case the AutoCoverage class would be
subclassed as:
■ PegaIns-Data-PolCmp-AutoCoverage-Com-Auto
■ PegaIns-Data-PolCmp-AutoCoverage-Pers-Auto
Figure 4-7. Example of Inheritance from PolComp Class
Inheriting from the PegaIns-Interface- Class Structure

The PegaIns-Interface- classes contains classes that are used to build
interfaces and API’s to external systems. By inheriting from these classes,
you can leverage the existing rules set up to facilitate data access. The
interface classes that are included in the Framework are:
■ PegaIns-Interface-Contact
■ PegaIns-Interface-Contact-PolicyRoleSummary
■ PegaIns-Interface-InsurancePolicy
■ PegaIns-Interface-PolicyLink
■ PegaIns-Interface-AgencyLOB
■ PegaIns-Interface-Roles
Working with Insurance Work Objects

The Framework includes the following work objects:
■ Applications (new business )
■ Service – Change Policy (endorsements)
Work objects are intended to be at the front-end of processing or to link to

back end systems such as Policy Administration or Document Management.
Although, the Framework can be used as the system of record, in most

cases the system of record will be external to the Framework. In these cases,
the Framework acts as an integrator, binding other systems together and
managing exceptional cases not handled elsewhere, such as manually
priced policies, or other operational issues best handled outside of existing
systems.
The flow structure for each work type is similar. Each flow is controlled by a
main flow that calls the appropriate subflows for the work type. They follow
the basic structure of ‘entering party data’, ‘entering data for the work type’,
and ‘processing the work type’. The flows for each work type are discussed
on the following pages.
Application – New Business

Applications for insurance after being entered and successfully processed
result in the issuance of insurance policies. In the Framework, examples are
provided showing how the Product Configuration Framework can be used to
drive the processing of Manually Priced policies. The actual document
production is assumed to be handled externally. The system of record may or
may not be an existing system.
Extension Tip: The Framework writes the policy image to an external

database table defined for the PegaIns-Interface-InsurancePolicy class.
This is configured for demonstration purposes. During implementation you
must create your own set of classes that have their own activities that pre-
empt those in the PegaIns- layer.
The following figures show the preconfigured flows shipped with the
Framework that comprise the New Business process. The Application flows
have been built to show the Quote, Underwrite, Bind and Issue steps
involved in processing an Application. As previously mentioned, the
NewWork flows for Applications exist in the subclass for the particular
product group, for example: Personal Auto or Homeowners. Each NewWork
flow (Figure 4-8) calls the Application Main flow (Figure 4-9) that is common
to all product groups.
Figure 4-8. Personal Auto NewWork Flow

Figure 4-9. ApplicationMain Flow
The EnterPartyData subflow (Figure 4-10) that is specific to Applications

collects the party data for the Applicant. The party data is entered through
the contact search functionality.
Figure 4-10. EnterPartyData Subflow
The IIFAppContactSearch subflow (Figure 4-11) is called with a flow

parameter of “Applicant”, so that when the contact is selected, the data is
moved into the pyWorkParty page group for the “Applicant”. The
IIFAppContactSearch subflow is common to all work types in the Framework
and lives in the PegaIns-Work class.
If this work is being executed by an agent, the Agent work party is populated
with the Agent’s information from the AgentProfile page on the clipboard.
The flow calls the PopulateAgentData activity to handle this process.
Figure 4-11. IIFAppContactSearch Subflow
The ProductSelection subflow for Applications (Figure 4-12) handles the

process of producing a list of products to select from and setting up the policy
with the product selected.
Figure 4-12. ProductSelection Subflow
The EnterApplicationData flow (Figure 4-13) handles the process of entering

the detailed data for the policy. It then presents the entered data for
confirmation from the customer.
Figure 4-13. EnterApplicationData flow
The ProcessApplication flow (Figure 4-14) handles the steps needed to

process the application once all the data has been entered and validated. It
calls the ApplicationQuote subflow (Figure 4-15) that handles producing a
Quote and sending it to the customer for acceptance. If the customer accepts
the quote, it then spins off the BackOffice flow (Figure 4-16) that handles the
processes of Underwriting, Binding and Issuing the Application.
Figure 4-14. ProcessApplication Flow

Figure 4-15. ApplicationQuote Subflow

Figure 4-16. BackOffice flow

The BackOffice flow needs to be called via a spin-off flow shape to allow the
back office functions to be handled via the Framework even when the
application was handled by another system or framework application such as
CPM for Insurance. The back office functions include Underwrite (Figure
4-17),Bind Policy (Figure 4-18), and Issue Policy (Figure 4-19) which are
each handled by subflows.
Figure 4-17. ApplicationUnderWrite Subflow

Figure 4-18. BindPolicy Subflow
Figure 4-19. IssuePolicy Subflow

Understanding the Preconfigured Workflows

In this release of the Framework, the work classes for Applications
processing are specialized by Line of Business (LOB), such as Commercial
or Personal, and product group, which is defined in the Product Configuration
Framework layer. Examples of product groups are Auto and Business
Owners Policy (BOP) for Commercial LOB and Auto and Homeowners for
Personal LOB. The product group is a concrete work class under the class of
the current work pool. Each product group can have many products defined
for them in the Product Configurator. There is an Application flow for each of
the product groups. A NewWork flow exists in each of the lowest level work
classes defining the product groups. When an Application flow is initiated,
data is collected for the appropriate work parties. These work parties are
defined in the Rule-Obj-WorkParties rule at the class level for the line of
business that is chosen. For example, if ‘Personal Lines’ is chosen for the
line of business, the WorkParties rule is found in the class PegaIns-Work-
Application-Pers-.
To facilitate entering party data, users are taken through the Contact Search
functionality. After the contact data is entered, a list of available products
displays in a selection list. This list is created from the products that are
defined in the Product Configuration layer for the product group associated
with the work object.
Figure 4-20 lists the Work- classes containing rules that filter the information.
Figure 4-21 shows an example of the filtering during the entry of a
Commercial Lines application.
Figure 4-20. Business and Product Filtering
Figure 4-21. Product Filtering

The Entry process for applications may be driven by the Product

Configuration Framework or may be custom crafted for Policy Administration
system resident products. Figure 4-22 shows the flow used to enter
application data.
Figure 4-22. EnterApplicationData Flow
If the Product Configuration Framework drives the process, there are actions
that allow users to select a different product within the same Line of
Business, to enter details for the selected product, and to confirm or reenter
the same. The detail screens presented to the user depend on the product
selected.
ChgPolicy – Endorsements
The ChgPolicy work type and flows handle the processing of Endorsements
(or Mid-Term Adjustments). The framework includes flows that process In-
Sequence Endorsements and can be extended to support Out-of-Sequence
endorsements. The following figures show the preconfigured flows shipped
with the Framework that comprise the ChgPolicy process. The ChgPolicy
NewWork flow (Figure 4-23) is the main flow that controls the required
processing steps by calling the appropriate subflows.
Figure 4-23. ChgPolicy NewWork Flow

The EnterPartyData subflow (Figure 4-24) that is specific to ChgPolicy

collects the party data for the Policyholder. The party data is entered through
the contact search functionality. The IIFAppContactSearch subflow is called
with a flow parameter of “Policyholder”, so when the contact is selected, the
data is moved into the pyWorkParty page group for the “Policyholder”. The
IIFAppContactSearch subflow is common to all work types in the Framework
and lives in the PegaIns-Work class.
If this work is being executed by an agent, the Agent work party is populated
with the Agent’s information from the AgentProfile page on the clipboard.
The flow calls the PopulateAgentData activity to handle this process.
Figure 4-24. ChgPolicy EnterPartyData Subflow

The next step is to select a policy to apply the change. The SelectPolicy flow (Figure 4-25)
handles the steps needed to display a list of policies for the Policyholder and gathers the
policy data for the policy that is selected from the list. If you are executing this flow in a
CPMINS implementation, the policy data is already retrieved, bypassing this part of the flow.
Similarly, if the policy is present (the policyid is not blank), then the policy list is bypassed and
control goes directly to FetchPolicyData.
Figure 4-25. ChgPolicy SelectPolicy Flow

The PerformEndorsement flow (Figure 4-26) handles the entering and

processing of the endorsement data.
Figure 4-26. ChgPolicy PerformEndorsement Flow
The EnterEndorsementData flow (Figure 4-27) displays the data for the
policy that was selected and allows the data to be modified.
Figure 4-27. ChgPolicy EnterEndorsementData Flow
After modifications are made, a new price is calculated. A Premium

Summary area is shown to identify the new premium, the current premium
and the change in premium that is a result of the changes made to the policy.
Figure 4-28 shows this Premium Summary on the confirmation screen.
Figure 4-28. ChgPolicy Confirm Product Details Screen
On the ChgPolicy screens, there are two buttons at the top of the screen as
seen in Figure 4-28. When clicked, the first button, View Endorsement
History, gives a list of previous endorsements for this policy in a pop-up
window. One can click on any of these to see the policy details for this
endorsement. The second button, View Endorsement Basis, shows the
policy details for the current version of the policy, which is the basis for this
endorsement.
After the desired changes have been made to the policy and confirmed,
control is then sent to the ProcessPolicyChanges flow (Figure 4-29). This
flow first calls the ReQuote subflow (Figure 4-30) to handle the Re-Quote
process and sends it to the customer for acceptance. If the customer accepts
the re-quote, it then spins off the BackOffice subflow (Figure 4-31) to handle
the processes of Underwriting, Binding and Issuing the Endorsement.
Figure 4-29. ChgPolicy ProcessPolicyChanges Flow

Figure 4-30. ChgPolicy ReQuote Subflow

Figure 4-31. ChgPolicy BackOffice Subflow

Configuration of Products (Policies)

The Product Configuration Framework included in the Insurance Industry
Framework allows administrators to define products “as they may be sold”. In
the Insurance Framework, class structures have been created to represent
Products and Product Components. The Products are grouped by Lines of
Business. The Product Components are more generally grouped and are
based on classes defined in the PegaIns-Data-PolCmp class. These classes
should inherit from Piif classes. The Piif classes were created from IAA’s
Interface Design Model (IDM) and contain a multitude of properties that can
be used to assemble insurance objects. Figure 4-32 shows the structure of
the classes based on this model.
Figure 4-32. Classes Based on the IAA Model
Rule-PegaSP-Product records are defined with the classes listed in Figure

4-32 as the “applies to” class with corresponding work- classes as the “entry
process class”. Products represent Insurance Policies which are composed
of “components” (and sub-components nested to an arbitrary level), and
“features”. In the Framework, components represent Insured Objects and
Coverage Options.
Figure 4-33 shows the products (Insurance Policies) available for the
Commercial Lines as displayed by the system’s Product Explorer. The
Product Explorer is available from the Edit menu on the task bar located at
the top of the workspace.
Figure 4-33. Product Explorer For Commercial Lines – BusinessOwnersPolicy Tree

Figure 4-34 shows an example of the product component definition for the
BusinessOwnersPolicy shown in the Product Explorer in Figure 4-33.
Figure 4-34. Product Definition for BusinessOwnersPolicy

Pricing Details
IAA assumes that there will always be an “exposureAmount” property related

to insurance policies or insurance policy components. Therefore, a PegaIns-
Work-Application specific version of the ActionFinalCheck activity is
provided. This is a post-processing activity that executes validations and
calculates prices after policy data entry. The PegaIns-.Figure_Exposure
activity was added to loop through all components and all features and
calculates a component instance’s exposureAmount as the sum of all the
exposureAmount values in its selected features. That way, pricing is directly
related to the exposureAmount property. See Chapter 5 — Pricing Rules and
Models for more details on the pricing functionality in the framework.
Figure 4-35 shows how pricing details appear to an online user.
Extension Tip: If the final amount is not a simple sum, you will have to
create component class specific calculation routines and insert them into
this process. Pricing for the BOM policy example follows this model.
Figure 4-35. User View of Pricing Details

Agencies and Agents

An Agency acts as an intermediary between an insured and carrier.
Agencies generate new business and process requests for servicing existing
business. The typical insurance policy is linked with one Agency. A Master
Agency Code is used as a method for aggregating all of the Agency data. An
Agent is an employee of the Agency. The Agent is the central point of
contact with the insured and the carrier. An Agency may process multiple
lines of business for the carrier. Each line of business may have a different
effective date for processing and commission percentage. There is a license
that must be obtained to write a line of business in each state. This licensing
information is a key piece of information to be linked to the Agency. The
relationship is illustrated in Figure 4-36.
Figure 4-36. Agency-Agent Relationship

Agencies
Master Agencies and Agencies are stored in the PA_BUSINESSUNIT table.
The relationship between them is stored in the PA_BUSINESSUNIT_LINK
table. The Agency LOB data is stored in a new table IIF_AGENCY_LOB.
See Chapter 6 and Appendix A for more information on this table. The keys
to the AgencyLOB table are:
AgencyCode, LineOfBusiness, LicensedState, EffectiveDate
Agents
Agents are stored in the PA_CONTACT table. Each agency also can have
many agents working for it. This relationship is stored in the
PA_CONTACT_BUSINESSUNIT_LINK table.
Agent Profiles
An operator on the system can be either an agent or a representative of the
carrier performing work on behalf of the agent. When the operator is an
agent, an AgentProfile is created at the time the operator signs onto the
system. The link between the operator and agent is in the AgentProfile
decision table. The AgentProfile contains the agent and agency data for this
agent. This data is used in later processing. The following rules are involved
in creating the AgentProfile:
Code-Security.ApplicationProfileSetup Activity
This activity is invoked when the operator signs onto the system. It is
overridden in the PegaInsure ruleset with one line that is added to call the
BuildAgentProfile activity.
PegaIns-Data-AgentProfile.BuildAgentProfile Activity
This activity is responsible for creating the AgentProfile page on the
clipboard. This page contains agent and agency information for the operator.
It looks the operator up in the AgentProfile decision table to get the
AgentCode (contact id) and AgencyCode (business unit id) for this operator.
The agent and agency data are then read from the PA_CONTACT table and
the PA_BUSINESSUNIT table using these values as keys.
PegaIns-Data-AgentProfile.AgentProfile Decision Table

This table (Figure 4-37) maps the operator to an agent code (contact id) and
an agency code (business unit id). The framework is shipped with a sample
agent that has an associated operator record, TSmith@TomsInsAgency.
The decision table that is shipped contains information for this operator.
Figure 4-37. AgentProfile Decision Table
Associating Agencies to Policies

Agency data is stored in the policy as an embedded page of the class,
PegaIns-Data-Party-Org-Agency. A new AgencyData property is created in
the PegaIns-Data-InsurancePolicy class for this embedded page. This
property is displayed in a new DisplayAgency section whenever the policy is
displayed. When a new policy is created in the New Business flow, this
agency data is populated in one of two ways.
1. If the operator is an agent, then his AgentProfile exists on the clipboard.

The agency data is copied to the AgencyData page property in the policy
which is displayed read-only in the policy information area of the screen.

The agent data is copied to the ‘Agent’ work party in all new work objects
he creates.
2. If the operator is not an agent, the AgencyData display on the screen is

updateable and the operator selects an agency to assign to the policy.
This information is required.
Figure 4-38. AgencyDisplay Section
PegaIns-Work-Application.InitializeNewPolicyData Activity
This activity is called when a new policy is created in the new business
process to set initial data. This is used to set the AgencyData property when
the operator is an agent and the AgentProfile page exists on the clipboard.
PegaIns-Data-Party-Org-Agency.GetAgencyData Activity
This activity is called from an OnChange event defined on the AgencyCode
property in the AgencyDisplay section. When a value is put into the
AgencyCode field, this activity is called to retrieve the agency data from the
database and populate the AgencyData embedded page in the policy.
Sample Agent and Agency Data

The framework is shipped with sample agency and agent data. This sample
data is described in the following tables:
Master Agencies
AgencyCode Name Address City State
ABC ABC Brokers 123 Main St Alexandria NY
MAINEAG Maine Agency 543 Main St. Adjuntas ME
SMITHINS Smith Insurance Agency 510 Maple St. Boston MA
Agencies
Agency MasterAgency Name Address City State
Code
TOMSINS Smith Insurance Toms Insurance 1420 Newton St Needham MA
Agency Agency
1000 ABCBrokers ABC Brokers 123 Main St Alexandria NY
1001 ABCBrokers Faifax Agency 562 Main St Alexandria NY
2007 Maine Agency Maine Agency 543 Main St Adjuntas ME
2008 Maine Agency Jones Agency 571 Main St Charlotte ME

Amalie
Agency Lines of Business

Agency LOB State Effective Expiration Commission
Code Date Date %
TOMSINS Personal Auto MA 10/9/07 12/31/99 15
TOMSINS Personal Auto NH 10/9/07 12/31/99 15

Agency LOB State Effective Expiration Commission

Code Date Date %
TOMSINS Homeowners MA 10/9/07 12/31/99 8
TOMSINS Commercial Auto MA 10/9/07 12/31/99 10
TOMSINS Life MA 10/9/07 12/31/99 8
1000 Personal Auto MA 1/1/07 12/31/99 10
1000 Homeowners MA 1/1/06 12/31/99 15
1000 BOP MA 1/1/05 12/31/99 15
1000 Commercial Auto MA 1/1/07 12/31/99 10
1000 Life MA 1/1/07 12/31/99 8
1001 Personal Auto MA 1/1/07 12/31/99 10
1001 Homeowners MA 1/1/06 12/31/99 15
1001 BOP MA 1/1/05 12/31/99 15
1001 Life MA 1/1/07 12/31/99 8
2007 Personal Auto MA 1/1/07 12/31/99 10
2007 Homeowners MA 1/1/06 12/31/99 15
2007 BOP MA 1/1/05 12/31/99 15
2007 Life MA 1/1/07 12/31/99 8
2008 Personal Auto MA 1/1/07 12/31/99 10
2008 Homeowners MA 1/1/06 12/31/99 15
2008 BOP MA 1/1/05 12/31/99 15
2008 Life MA 1/1/07 12/31/99 8

Agents
AgentId Name Agency
CONTA-100 Tom Smith Toms Insurance Agency
CONTA-110 Joan Smith Toms Insurance Agency
CONTA-120 Ethan Frome ABC Brokers
CONTA-130 Pat Kenzie Fairfax Agency
CONTA-140 Jacob Larson Maine Agency
CONTA-150 Jim Jones Jones Agency

Matching Drivers to Vehicles

When determining the premium for an automobile policy, the process
requires associating (matching) drivers to vehicles so that consideration of
the risk involved for each vehicle is appropriate for the driver. The risk
assessment is based on the primary driver for the vehicle. Processing follows
the logic below:
■ The driver (using age, driving record, college, etc.) and the vehicle (using
age, coverage, repair cost, theft risk, and so on.) are rated separately.
■ Next, the combined derived risk is determined. The rating of vehicles and
drivers is numeric — the lower the value, the lower the risk of loss
expected.
■ The vehicles and drivers are associated using a method described in the
section below or some other method.
■ Once the vehicles and drivers have been associated, and the combined
vehicle-driver risk value for each is derived, the process moves to
calculating the price. Pricing is different for each company. This can
involve quantity and multi line discounts, and the algorithms used for
aggregating the total risk and discount may vary greatly. See Chapter 5:
Pricing Rules and Models of this document for information about pricing
models used in the Framework.
Driver/Vehicle Association Methods
There are a number of methods that can be used to make the association
between drivers and vehicles. Some approaches are related to the corporate
policy for the carriers while others are legally mandated,to limit how negative
a consideration a company can make. Common methods are:
■ Method 1 – Customer specification
In this method the driver-vehicle pairs are defined by the customer. It allows
the customer to specify the primary driver of a given vehicle.
■ Method 2 – Highest Pairings
Following the rating of the drivers and vehicles, the lists are ordered from
highest to lowest. Iterating through the list of vehicles from highest to lowest
rated, look for the driver with the highest rating who is not associated with
any vehicle. Associate the driver with this vehicle.
If there are vehicles remaining after matching all available drivers, the list of
drivers is reused starting from the beginning of the list.
■ Method 3 – Highest Pairing with Specification
This method is an addition to the process defined in Method 1. In addition to

specifying the primary driver of a vehicle, the customer is allowed to specify
certain other associations such as their oldest vehicle is driven by their teen-
ager, while their newer or more expensive car is driven by an older adult.
Pre-associated pairs are removed from the first iteration through vehicle list
and the rest of the process uses Method 1.
■ Method 4 – Highest Pairing with Exclusion
The exclusion method is where a driver is explicitly excluded from driving a

specific vehicle. The driver and vehicle are both still in consideration for all
possible matches. However, the driver is not permitted to drive the vehicle
under any circumstances as they would be uninsured.
This association method is implemented to mitigate a situation like having a

newly licensed 16 year old and a brand new high performance exotic sports
car in the same household.
How the Framework Associates Drivers to Vehicles

The PersonalAuto sample product in the Framework uses Method1 to
associate its vehicles and drivers. When entering information, the customer
specifies the principal driver of each vehicle in the NamedDriver property.
Because of the complexity of the product data structure and how it

represents components with a series of embedded pages, the vehicle to
driver associations are determined in the beginning of the pricing process
and stored in the VehiclesToDrivers property located in the PegaIns-Data-
InsurancePolicy class. By storing the information here, it is readily available
at the time the pricing activities are invoked and eliminates the need for the
pricing activities to traverse the product structure to find the associated driver
information.
The PegaIns-Data-InsurancePolicy VehiclesToDrivers property has a data

type of page group in the PegaIns-Data-VehiclesToDrivers class. The value
for the page group index is Vehicle1, Vehicle2, Vehicle3, etc.
The PegaIns-Data-VehiclesToDrivers class contains the following properties:
■ DriverIndex — contains the integer values for the NamedDriver that is

assigned to the vehicle
■ DriverAgeCategory — is populated with a rating information for the

specific driver
■ DriverRecordCategory — is populated with rating information for the

specific driver
In a scenario where there are two vehicles and two drivers, the
VehiclesToDrivers property structure resembles the sample in Figure 4-39
indicating that the Driver specified in the second element of the NamedDriver
pagelist is matched with the vehicle specified in the first element of the
InsuredVehicle pagelist and so on:
VehiclesToDrivers Property Properties Value
Vehicle1 Driver Index 2

DriverAgeCatgory Low
DriverRecordCategory Good
Vehicle2 Driver Index 1

DriverAgeCatgory High
DriverRecordCategory Good
Figure 4-39. Sample Property Structure for Two Vehicles and Drivers
This property is populated at the beginning of the pricing process. The

activity, PegaIns-Data-InsurancePolicy-Personal-
Automotive.MapVehiclesToDrivers, is executed as the first step in the pricing
activity that walks through the named driver array and populates the
VehiclesToDrivers page group. There is one data element for each driver but
not necessarily for each vehicle. In a case where there are 3 vehicles and
only 2 drivers, there would be only two elements in the VehiclesToDrivers
page group.
Once the VehiclesToDrivers property is populated, it is available for use in

the pricing activities that calculate a price for a given vehicle.
How to Extend the Matching Drivers to Vehicles Functionality

There are three configuration points in the Framework where the matching
functionality can be extended:
1. Add properties to the VehiclesToDrivers class that are needed to meet

additional pricing requirements.
2. Override the PegaIns-Data-InsurancePolicy-Personal-

Automotive.MapVehiclesToDrivers activity to implement different
mapping algorithms for matching drivers to vehicles.
3. Override the logic to rate the drivers and vehicles. This logic is
implemented in the pricing activity for a given auto coverage
component. For example, the activity PegaIns-Data-PolCmp-
AutoCoverage.CalculateBodilyInjury contains the steps to calculate the
driver rating that it utilizes.
Chapter 5
Pricing Rules and Models
This chapter describes how pricing is set up in the Insurance Industry

Framework and provides information about developing your own pricing
models. It includes the following topics:
■ Pricing Overview
■ Standard Pricing Rules
■ Business Owners Policy Pricing Model
■ Term Life Pricing Model
■ Variable Universal Life Pricing Model
■ Automotive Pricing Model
■ Homeowners Pricing Model

Pricing Overview
Pricing calculations are used to calculate the premiums for coverages
included in an insurance policy and for the policy itself. These pricing
algorithms are very specific to the product examples shipped with the
framework and are in themselves examples of how pricing can be
implemented.
The pricing calculations are implemented procedurally using activities, rather

than declaratively with Process Commander’s declarative network. It is
expected that you will replace the Framework’s pricing activities with
activities that meet the pricing requirements of your business. Because the
Insurance Industry Framework uses the Product Configuration Framework to
represent an insurance policy and its coverages, references are made to the
Product Configuration layer and its rules. See the Product Configuration
Frameworks documentation for a more detailed description of this
functionality.
The activities used to calculate the price for a given product and its
components are specified in the Product Configuration product and
component rules. The activity RunCalculations, used to initiate the pricing
process, is invoked from a step in the post processing activity,
ActionFinalCheck, called from the EnterProductData flow action. The logic
loops through the product tree and calls the pricing activity defined in each
component rule from the bottom up.
Extension Tip: When extending the framework to meet individual

business pricing needs, any of these pricing activities can be overridden
or extended. To replace the entire pricing functionality, the
ActionFinalCheck activity should be overridden. The
CalculateProductPrice activity, called from RunCalculations, is a good
example that shows how to walk down the Product Configurator product
structure on the clipboard. It uses many embedded pages to calculate
prices for components and subcomponents and roll those prices up
product hierarchy.
Pricing Rules and Models 5-3
One of the requirements across all insurance products is that each coverage
have a premium associated with it and, therefore, needs to be able to have a
pricing calculation applied to it. In order to meet this requirement, all
coverages are implemented as components in the Product Configuration
Framework layer (as compared to features). This allows a pricing activity to
be specified in the component rule for any given coverage.
The algorithms used in calculating the price for the example products that are
included in the Framework, along with the activities that implement them, are
described on the following pages for each example product. The Personal
Auto pricing rules show an example of how to use circumstancing to handle
pricing rules that vary by state.
Standard Pricing Rules

There are a number of standard pricing rules provided in both the Product
Configurator and Insurance Industry Frameworks. The Product Configurator
pricing rules are generic and provide the ability to connect the product and its
components and subcomponents in calculating the price. For example, the
price of a product is the sum of all the component prices. The pricing rules
provided by the Insurance Industry Framework implement a general pricing
algorithm specifically for coverages.
The pricing activities provided in the Product Configurator Framework are

found in the PegaSP class. There are activities that calculate the price using
a decision table, a decision tree, or by expressions, calculate taxes and apply
discounts at all levels of the product structure. You can explore these rules to
become more familiar with them, only those used in the Insurance
Framework are discussed here.
The pricing activities provided in the Framework implement both general

algorithms that apply to all types of coverages and specific algorithms that
are used by the example products provided in the framework.
Pricing Activities in the Framework
General Pricing Activities for Coverages

The price of a coverage is calculated by the general algorithm:
exposureAmount * a rate * an adjustment.
The exposureAmount, which is the amount of risk that the insurance

company carries, is calculated by the InsuredValue (sometimes called
CoveredAmount) less any DeductibleAmount.
The rate and adjustment percentages are determined in decision tables that
belong to the class of the component that is referencing it. The rate decision
tables are based on the DeductibleAmount. The greater the deductible
amount, the less risk is given to the carrier, which is reflected in the rate
tables. The adjustment decision tables are based on the exposureAmount of
the coverage. The general pricing activity that implements this algorithm and
can be used for all coverages is PegaIns-Data-PolCmp.CalculatePrice. This
CalculatePrice activity is sometimes extended in the class of the associated
component.
PegaIns-Data-PolCmp-.CalculatePrice Activity
Input parameters: Rate table
Adjustment table
This activity is a standard CalculatePrice activity that follows a basic

calculation to determine a premium for a coverage.
coverage premium = exposureAmount * Rate * Adjustments
.exposureAmount = InsuredValue – DeductibleAmount
The Rate and Adjustment values are determined from decision tables that
are passed in as parameters. The InsuredValue and DeductibleAmount
values are specified by the customer at data entry.
Rate Tables
There are a number of sample rate tables included in the framework. The
values in each table are specific to the type of component and the
component class:
The decision table for the rate is named SpecifiedItemRate. This table exists
in the class of the component the price is being calculated for.
In the PegaIns-Data-PolCmp-BuildingCoverageBenefit class the table is

based on deductible amount:
If .DeductableAmount <= 500 the rate is .003
Else if .DeductableAmount <= 1000 the rate is .0027
Else the rate is .002
The decision table for the adjustment is named SpecifiedItemAdjustment:

If exposureAmount < 1,000,000 then the adjustment is .1
Else If exposureAmount >= 1,000,000 and < 5,000,000 then the
adjustment is .12
Else If exposureAmount >= 5,000,000 then the adjustment is .15
Else the adjustment is 1.
Pricing activities in the PegaSP Class

The PegaSP pricing activities used by the Framework are described here.
Explore the PegaSP class for a full listing of the pricing activities available.
ProdSumcomponentsWithDiscount Activity
This activity sums all the component and subcomponent prices into the
product price and then applies a discount to the product and subcomponent
prices. The discount is passed as a parameter.
1. It first calls ProductSumOfCompPrices that loops through all the

components and subcomponents and sums up the .SPPrice values into
the product .SPPrice property and the .exposureAmount values into the
product .TotalexposureAmount property.
2. Then, it applies the discount (passed in as a parameter) to the product

price and cascades this discount down to the component and
subcomponents by calling the DiscountProdAndComps activity.
3. The DiscountProdAndComps activity first applies any discount to the

product price by calling DiscountProductPrice which uses following
logic:
− Multiplies the value in .SPPrice by the discount supplied by the
parameter and puts result into property .SPAdjustedPrice.
− The DiscountProdAndComps activity then applies the discount to all
components and subcomponents by iteratively calling
DiscountComponentPrice, DiscountSubcomponentPrice, and
DiscountProductPrice.
ProductSumOfCompPrices Activity
This activity sums the prices for the first level of components under a product
and rolls them up into the total price for the product.
It loops through the first level of components in the product and sums up the
.exposureAmount in the .optionData page into the TotalexposureAmount
property and .SPPrice in the optionData page into the .SPPrice property for
the product.
The following sections describe the specific pricing algorithms used by the
sample products provided in the Framework.
Business Policy Owner’s Product Pricing Model

The Business Owners Policy (BOP) product and component structure is a
representation of a BOP policy and the coverages it can contain.
Each policy can have a number of property locations. Each property location
has a postal address. Each property location is defined to have Business
Interruption coverage, Content Coverage, and can have multiple buildings
defined for it. Figure 5-1 illustrates the product and component structure
displayed by the Product Explorer. Each building has coverages as well as
the Content Coverage component has various coverages. The BOP product
also has a General Liability component with its coverages.
Figure 5-1. BOP Product and Component Structure
The price calculations for a Business Owner’s Policy are:
BOP price = (sum of all Location premiums + GeneralLiability

Premium) * 10% discount
Location Price = BusinessInterruption Premium + sum of all Building

Premiums + ContentCoverage premium
BusinessInterruption Premium = uses the standard PegaIns-Data-

PolCmp-.CalculatePrice activity using the BusinessContinuationRate
rate table.
Building Premium, Content Coverages and SpecifiedItem premium =

sum of their sub-component prices
The basic coverages, Theft, Fire and Flood, are defined for the buildings,
content coverage and specified item components. They are defined in the
PegaIns-Data-PolCmp-BuildingCoverageBenefit class and have the same
pricing algorithm as the coverages in the Homeowners Policy. Each of these
coverages uses the general PegaIns-Data-PolCmp-.CalculatePrice activity
(described in the General Pricing Activities for Coverages section) and the
SpecifiedItemRate table in the PegaIns-Data-PolCmp-
BuildingCoverageBenefit class. No adjustment is applied to the price
calculation for these coverages.
In the PegaIns-Data-PolCmp-BuildingCoverageBenefit class the rate table is

The calculation for the premium is:
GeneralLiability Premium = sum of its Subcomponent prices, Fraud

nd SexHarassment
Fraud and SexHarassment coverages also use the general PegaIns-Data-

PolCmp-.CalculatePrice activity referencing the General Liability Rate table
and General Liability Adjustment Table.
Figure 5-2 lists the pricing activities called for each of the Business Owner
Policy components
Product/Component Pricing Activity
BOP Product PegaSP.ProdSumComponentsWith Discount

(passing a discount parameter of 10%)
Location PricePlusSumOfSubcomponentPrices
BusinessInterruption CalculatePrice
Building PricePlusSumOfSubcomponentPrices
TheftCoverage CalculatePrice
FireCoverage CalculatePrice
FloodCoverage CalculatePrice
ContentCoverage SumOfSubcomponentPrices
SpecifiedItem PricePlusSumOfSubcomponentPrices
GeneralLiability PricePlusSumOfSubcomponentPrices
Fraud CalculatePrice
SexHarassment CalculatePrice
Figure 5-2. Business Owners Policy Pricing Activities
PricePlusSumOfSubcomponentPrices Activity
This activity first determines the Content Coverage Price and then rolls up
the subcomponent prices into the total price for the Content Coverage.
It determines the Content Coverage Price by multiplying the value insured

amount by a rate. The value insured amount is in the .CoverageAmount
property that is populated from data entry. The rate is determined by a
decision table called ContentRateTable that is passed in as a parameter from
the component rule:
If the .CoverageAmount > 20,000 then the rate is .02
Else if the .CoverageAmount > 10,000 then the rate is .025
The Content Coverage Price is then calculated as the .CoverageAmount *

rate.
The total price of the subcomponents is then summed up by looping through

them and totaling the .SPPrice for each subcomponent. This total
subcomponent price is then added to the Content Coverage Price and the
result is stored in the .SPPrice property for the Content Coverage
component.
Term Life Pricing Model

The Term Life example product currently contains only one component
named TermLife. Its product structure is defined in the Product Explorer as:
Figure 5-3. Term Life Product Structure
The pricing calculation used to calculate a TermLife premium is:
TermLife price = CoverageAmount * TermLifeRate (based on age of

insured)
The pricing activities used here are specific to the TermLife product and do
not use the generic CalculatePrice activity. Figure 5-4 lists the TermLife
components and pricing activities.
Component Pricing Activity
TermLife Product (product) PegaSP.ProductSumOfCompPrices
TermLife (component) PricingByAgeAndDecisionTable

Figure 5-4. Term Life Pricing Components
PricingByAgeAndDecisionTable
This activity is in the PegaIns-Data-PolCmp-InsuredLife class and is used
only in calculating the TermLife price. This activitiy is referenced in the
TermLife component rule. It determines a rate based on the age of the
insured person. It then multiplies the .CoveredAmount entered on the screen
by this rate. The decision table it uses is PegaIns-Data-PolCmp-
InsuredLife.TermLifeRates. The decision logic is:
If the age of the insured is between

20 and 39 the rate is .05
Variable Universal Life Pricing Model

The Variable Universal Life (VUL) example product that is provided in the
framework currently contains only three components. The product structure
is defined in the Product Explorer as:
Figure 5-5. Variable Universal Life Product Structure
The price calculation for a VUL policy is:
VUL price = Price for BasicDemographicInformation + Price for

BasicPolicyInformation + Price for RiderInformation.
BasicDemographicInformation Price = CoveredAmount * rate based on age

and smoker * rate based on frequency of payments.
BasicPolicyInformation Price = InvestmentGoal * .00094 * rate based on

frequency of payments
RiderInformation Price = (ChildRiderAmount * .009) + (SpousalRiderAmount

* .009) + 200
The pricing activities used here are specific to the VUL product and do not
use the generic CalculatePrice activity. Figure 5-6 lists the pricing activities
that are called for each of the VUL components:

VUL Product (product PegaSP.ProductSumOfCompPrices
BasicDemographicInformation BasicDemographicInformation
BasicPolicyInformation BasicPolicyInformation
RiderInformation BasicRiderInformation
Figure 5-6. Variable Universal Life Pricing Activities
BasicDemographicInformation Activity
This activity is in the PegaIns-Data-PolCmp-InsuredLife class and used only

in calculating the BasicDemographicInformation price. It is referenced in the
BasicDemographicInformation component rule. It calculates the price using
two rates:
1. PaymentFrequencyRate uses the VarUnivLifeFrequenceDiscount table

and the payment frequency entered on the screen. Figure 5-7 shows
the relationship between the payment frequency value and the discount
rate.
Payment Rate
Fequency
1 .1
2 .05
4 .03
12 0
Other 0
Figure 5-7. Frequency Discouont Table
2. TermRate is set by the values set in the VarUnivLifeBasicDemoData

table and the age of the insured (Figure 5-8).
Age of Insured Smoker Rate Non-Smoker Rate
<=25 .0090 .00107
<=30 .0090 .00113
<=35 .00094 .00126
<=40 .00102 .00146
<=45 .00119 .00184
<=50 .00166 .00283
<=60 .00323 .00637
<=70 .00686 .01327
Default .2 .3
Else .3
Figure 5-8. Age and Smoker and NonSmoker Decision Values
It then multiplies the .CoveredAmount that is entered on the screen by these

rates using the following formula:
BasicDemographicInformation Price = (CoveredAmount * TermRate)

* (1 – PaymentFrequencyRate)
BasicPolicyInformation Activity
This activity is in the PegaIns-Data-PolCmp-InsuredLife class and used only
in calculating the BasicPolicyInformation price. It is referenced in the
BasicPolicyInformation component rule. It calculates the price using two
rates:
1. PaymentFrequencyRate – uses the VarUnivLifeFrequenceDiscount

table and the payment frequency entered on the screen. Figure 5-9
lists the rates for the ages of the insured.
2. LengthOfCoverageRate is set based on the

VarUnivLifeBasicPolicyData table and a hard coded
LengthOfCoverage value of 35.
AgeOfInsured Smoker Rate

<=25 .00090
<=30 .00090
<=35 .00094
<=40 .00102
<=45 .00119
<=50 .00166
<=60 .00323
<=70 .00686
Default .3
Figure 5-9 Age and Smoker Rate Table
It then multiplies the value of the .InvestmentGoal property entered on the

screen by these rates using the following formula:
BasicPolicyInformation Price = (InvestmentGoal *

LengthOfCoverageRate) * (1 – PaymentFrequencyRate)
BasicRiderInformation Activity
This activity is in the PegaIns-Data-PolCmp-InsuredLife class and is used
only in calculating the BasicRiderInformation price. It is referenced in the
RiderInformation component rule. It calculates the price using hard coded
rates and the .ChildRider and .SpousalRider values that are entered on the
screen in the following calculation:
RiderInformation Price = ((ChildRider * .009) + (SpousalRider * .009)

+ 200)
Automotive Pricing Model
Personal Auto
The Personal Auto Product structure contains both vehicles and named
drivers. The Vehicles are subcomponents of the GaragingLocations
components. Each vehicle has the coverages shown below in the product
structure displayed by the Product Explorer.
Figure 5-10. Personal Auto Product Structure
The pricing calculations for the Personal Auto are:
■ Personal Auto Premium = sum of Garaging Location Premiums
■ Garaging Location Premium = sum of Covered Vehicle Premiums
■ Covered Vehicle Premiums = sum of coverage premiums
Coverage Premiums are calculated by activities specific to the coverage

listed in Figure 5-11:

BodilyInjuryToOthers; CalculateBodilyInjuryPrice
BodilyInjuryFromUnderInsuredAuto
OptionalBodoilyInjuryToOthers; CalculateBodilyInjuryPrice
BodilyInjuryFromUninsuredAuto
PersonalInjuryProtection CalculatePersInjProtPrice
DamageToOthersProperty CalculateDamangeToOthersPropertyPrice
MedicalPaymentsPerPerson; Comprehensive CalculatePrice using GeneralAutoRate decision table
SubstituteTransportationl; TowingAndLabor CalculatePrice using GeneralAutoRate decision table
Collision CalculateCollisionPrice
LimitedCollison CalculateLimitedCollisionPrice
Figure 5-11. Automobile Specific Coverage Activities
Some of the coverage premium calculations have a more complicated

algorithm than the basic exposureAmount * rate * adjustment that is
implemented with Calculate Price. The BodilyInjury coverages and
DamageToOthersProperty use the driving record information for the driver
that is assigned to the vehicle that the coverage is being calculated for.
These pricing activities first determine the particular driver in the Named
Driver component that is assigned to the vehicle. This information is stored in
the DriverToVehicle page group in the top level page for the policy, the
ProductOptionsPage. The pricing activity looks at this page group to find the
index into the OptionData page list in the NamedDriver component for the
assigned driver pricing information.
Commercial Auto
The Commercial Automotive products are similar to the Personal Auto,
except that they do not have the NamedDriver component as seen in the
product structure display from the Product Explorer (Figure 5-12).
Figure 5-12. Commercial Auto Product Structure
The pricing activities are the same activities used for the Covered Vehicle
components, ignoring any data references to the Named Driver driving
record information.
Homeowners Pricing Model

Each policy is written for a single property location. This property location has
a postal address. Each property can have more than one building defined for
it. Each building can have content coverage and specified items. A building
for a homeowners policy is defined in IAA as a dwelling, which is a building
intended for humans to reside in. The theft, fire and flood coverages apply to
all levels of components in the policy.
The product structure, with its components and subcomponents, for a

homeowners policy is shown in the ProductExplorer (Figure 5-13).
Figure 5-13 Homeowner Product Strructure
The pricing calculations for Homeowners are:
HomeOwners premium = sum of all HomePropertyLocation

premiums.
HomePropertyLocation premium = sum of all Dwelling premiums.
DwellingPremium = (FireCoveragePremium +
FloodCoveragePremium + LossOfUseCoveragePremium +
ContentCoveragePremium)
ContentCoveragePremium = (TheftCoveragePremium +
FireCoveragePremium + FloodCoveragePremium +
SpecifiedItemPremium) and so on.
The four basic coverages provided in the Homeowners Framework product

are:
■ TheftCoverage
■ FloodCoverage
■ FireCoverage
■ LossOfUseCoverage
All are of the class PegaIns-Data-PolCmp-BuildingCoverageBenefit. Each

coverage uses the general PegaIns-Data-PolCmp-.CalculatePrice activity
(described above) using the SpecifiedItemRate table in the PegaIns-Data-
PolCmp-BuildingCoverageBenefit class. No adjustment is applied to the price
calculation for these coverages.
In the PegaIns-Data-PolCmp-BuildingCoverageBenefit class the rate table is

These four coverages are included in the Dwelling, ContentCoverage and

SpecifiedItem components. As described above, the premium is calculated
for each of the basic coverages, and then these premiums are summed up
and rolled up the hierarchy to determine a premium price for each of the
components in the product.
Chapter 6
Integrating with External Systems
This chapter describes how to integrate with other systems to either push or pull
data.
In most cases, an external system of record stores the policy information when
the Framework is deployed. In other cases, the insurance system built in Process
Commander will be the system of record where the data is stored in database
tables external to the Framework. This means that Party data and Policy data
must be recorded and retrieved from other systems.
There are a number of integration activities that perform specific functions such
as writing out policy data, searching for contact or policy data, or reading in the
policy data. The Insurance Industry Framework comes with sample integration
rules that you can extend in your RuleSet or use as models for creating new
integration rules. The following sections discuss these integration functions:
■ Integrating Contact Data
■ Integrating Policy Data
■ Integrating Agent and Agency Data

Integrating Contact Data
Contact Data, also referred to as Party Data, is stored as instances of the

PegaIns-Interface-Contact class. While the Framework uses the functionality and
rules provided in the PegaApp layer to handle Contact information, it uses a
subset of these rules to read, write and search the Framework’s contact
information. There are three groups of integration rules provided for handling
policy data:
■ Reading Contact Data Rules
■ Writing Contact Data Rules
■ Searching Contact Data Rules
Reading Contact Data Rules

Contact data is always read through the contact search functionality. The rules
listed in Figure 6-1 are the rules that are specific to reading the contact data that
you may need to modify when integrating with your contact database table. The
contact search rules are discussed in the corresponding section.
RuleType Class RuleName

Activity PegaApp-Interface-Contact AppReadContactInfo
Connect-SQL PegaApp-Interface-Contact AppGetContactInfo
Activity PegaApp-Interface-Contact AppListAddressesForContact

Connect-SQL PegaApp-Interface-Contact AppListAddressesForContact
Activity PegaApp-Interface-Contact AppCommOptionsForContact
Connect-SQL PegaApp-Interface-Contact AppListCommOptionsForContact
Activity PegaApp-Interface-BusinessUnit AppListBUsForContact
Connect-SQL PegaApp-Interface-BusinessUnit AppListBUsForContact
Activity PegaIns-Work IIFMapPartyDetails
Figure 6-1 Reading Contact Rules

The activities listed in Figure 6-1 are used in the contact search flow to read the
contact data once a particular contact has been selected and the ContactID is
known. They read the contact data by calling a corresponding Connect-SQL rule
that is listed in the table under the activity rule.
Integrating with External Systems 6-3
These activities are called from the PegaIns-Work.IIFAppGetContactDetails

activity which is called from the PegaIns-Work.IIFAppContactSearch flow. The
PegaIns-Work.IIFMapPartyDetails activity maps the data from the contact page
on the clipboard into the work object. See Chapter 3: What Is Already Setup for
more details about this flow and these activities.
Writing Contact Data Rules

The Framework uses the rules listed in Figure 6-2 to add new contact data to the
contact table. These integration rules will require modification if changes are
made to the contact storage.

Activity PegaApp-Work AppSaveContactRecordDetails
Activity PegaApp-Interface-Contact AppSaveContactRecordDetails
Connect-SQL PegaApp-Interface-Contact AppSaveQuickContactDetails
Activity PegaApp-Interface-Contact AppSaveNewAddressTypeForContact

Connect-SQL PegaApp-Interface-Contact AppSaveNewAddressTypeForContact
Activity PegaApp-Interface-Contact AppSaveNewCommOptsTypeForContact
Connect-SQL PegaApp-Interface-Contact AppSaveNewCommOptnTypeForContact
Figure 6-2. Writing Contact Data Rules
PegaApp-Work.AppSaveContactRecordDetails Activity
This activity is the controlling activity that writes out the contact data. It calls each
of the other activities listed in the table. Each called activity executes the
Connect- SQL rule listed directly below the activity in Figure 6-2 to write the data
to the database table.
Searching Contact Data Rules

The rules listed in Figure 6-3 are used to implement the Contact Data Search.
When the search is executed and the list of contacts is displayed, the rules listed
in Figure 6-1 handle reading the contact that is selected. See Chapter 3: What Is
Already Setup for details about the Contact Search functionality.

Activity PegaApp-Interface-Account AppReadContactList
Connect-SQL PegaApp-Interface-Contact AppListByContactID
Figure 6-3. Searching Contact Data Rules
PegaApp-Interfrace-Account.AppReadContactList Acitivity
This activity generates a list of contacts by running the Connect-SQL
AppListByContactID to execute the search.
Integrating Policy Data

The Application and ChgPolicy flows write policy data. The Framework emulates
this by saving images of the Product selections in PegaIns-Interface-
InsurancePolicy with a unique key generated and inserted in the .PolicyID
property. The unique key may be generated external to Process Commander, but
it must be recorded and returned to Process Commander so that work items
contain the key data. There are three groups of integration rules provided for
handling policy data:
■ Writing Policy Rules
■ Reading Policy Rules
■ Searching Policy Rules
Writing Policy Rules

Figure 6-4 lists the integration rules that may need to be modified to write to a
new policy table:

Activity PegaIns-Work WritePolicy
Activity PegaIns-Interface-InsurancePolicy SetExposedColumns
Declare-Index PegaIns-Interface-InsurancePolicy PolicyLink
Figure 6-4. Writing Policy Rules
PegaIns-Work.WritePolicy Activity
Writing the policy is handled by the WritePolicy activity. This activity does the
following:
■ Maps the insurance policy data from the embedded data page in the work
object, pyWorkPage.ProductData.ProductOptionData, to the policy interface
class, PegaIns-Interface-InsurancePolicy
■ Calls SetExposedColumns to set the values of the columns that are exposed
in the table
■ Copies work parties to PartiesToAgreement and handles the roles
■ Calls Obj-Save to save the instance of this PegaIns-Interface-

InsurancePolicy class to the database
The WritePolicy activity is called from the IssuePolicy activity. Because the
processing to issue a policy is different for New Business or Policy Change, the
IssuePolicy activity is applied to both the PegaIns-Work-Application and PegaIns-
Work-ChgPolicy classes.
PegaIns-Interface-InsurancePolicy. SetExposedColumns Activity

Policy data is written out by Process Commander as a blob, with a set of
exposed columns to facilitate policy searching. The PegaIns-Interface-
InsurancePolicy.SetExposedColumns activity handles the setting of these
columns.
PegaIns-Interface-InsurancePolicy. PolicyLink Rule Declare Index

The Rule-Declare-Index instance (Figure 6-5) automatically populates the policy
link table.
Figure 6-5. PolicyLink Declare Index Rule

Reading Policy Rules

Figure 6-6 lists the integration rules that may need to be modified when reading
from a new policy table.

Activity PegaIns-Work FetchPolicyData
Activity PegaIns-Work-ChgPolicy PostFetchPolicyData
Figure 6-6. ReadingPolicy Rules
PegaIns-Work. FetchPolicyData Activity

This activity:
■ Reads policy data from the PegaIns-Interface-InsurancePolicy class using

the Obj-Open method
■ Maps the data to the work object in the embedded page of the class
PegaIns-Data-InsurancePolicy
■ Calls PostFetchPolicyData for any additional processing that may be needed
This activity is in the PegaIns-Work class because it implements common

functionality to read policy data across all types of work. Any specialized
processing for a given work type is done in the PostFetchPolicyData activity.
PegaIns-Work-ChgPolicy. PostFetchPolicyData Activity

Additional logic for reading a policy is needed in the ChgPolicy flow. For
example, the TransactionEffectiveDate is blanked out to be ready to be filled in
from the screen when executing the ChgPolicy flow.
Searching Policy Rules

Figure 6-7 lists the integration rules that may need to be modified to search a
new policy database table.

Connect-SQL PegaIns-Interface-InsurancePolicy IIFGetPolicyListForPolicyholder
Connect-SQL PegaIns-Interface-InsurancePolicy IIFGetPolicyListForPolicyholder_Date_D
ate_PolicyType
Connect-SQL PegaIns-Interface-InsurancePolicy IIFGetPolicyListForPolicyholderAndAuth
orizedParty
ListView PegaIns-Interface-InsurancePolicy ListPoliciesForPolicyholder
ListView PegaIns-Interface-InsurancePolicy ListPoliciesForPolicyholder_Date_Policy
Type
ListView PegaIns-Interface-Contact- ListPoliciesByContactAndRole

PolicyRoleSummary
ListView PegaIns-Interface-PolicyLink ListPolicyTransactions
Figure 6-7. SearchPolicy Rules

Integrating Agent and Agency Data

In the framework, agent data is stored as contacts in the PA_CONTACT table
and agency data is stored in the PA_BUSINESSUNIT table. The agents and
agencies are linked together through the PA_CONTACT_BUSINESSUNIT_LINK
table. The information above on integrating contact data can be applied to the
integration of agent data.
Part of the agency data is information about the Lines of Business that an agency
can write. This data is stored in the IIF_AGENCY_LOB table. Part of the key to
this table is the AgencyCode which links it to an agency. The agency data for a
particular policy is ultimately stored as an embedded page in the policy. There
are two integration points where the AgencyLOB data is accessed:
Creating the AgencyProfile for an operator that is an agent. An

AgencyProfile is created filling in agent and agency data for the operator.
Assigning an agency to a policy during the New Business flow. When an

operator is filling out a New Business application ‘On Behalf Of’ an
agent, the agency data is manually assigned to the policy.
The following table (Figure 6-8) lists the integration rules that may need to be
modified when accessing the agency lob data.

Activity PegaIns-Data-AgentProfile BuildAgentProfile
Activity PegaIns-Data-Party-Org-Agency GetAgencyData
Connect-SQL PegaIns-Data-AgencyLOB IIFGetAgencyLOBs
Figure 6-8. AgencyLOB integration rules
PegaIns-Data-AgentProfile.BuildAgentProfile Activity
This activity creates the AgentProfile page on the clipboard. It gets the agent and
agency data from the contact and business unit tables respectively using the
activites mentioned above. It then calls an RDB-List that executes
IIFGetAgencyLOBs to get the agency line of business data from the database.
PegaIns-Data-Party-Org-Agency.GetAgencyData Activity
This activity is called when an agency is manually assigned to a policy in the
New Business flow. When the AgencyCode is populated, this activity retrieves
the agency data for that AgencyCode.
The data is retrieved in two steps:
1. Agency data is retrieved from the business_unit table using the data in the
AgencyCode property
2. Agency Line of Business data is retrieved by calling an RDB-List that

executes IIFGetAgencyLOBs
PegaIns-Data-AgencyLOB.IIFGetAgencyLOBs Connect-SQL
This rule contains SQL that will need to be replaced with the correct SQL to get
your agency line of business data.
Chapter 7
Processing ACORD XML Messages
The chapter describes the design and processing flow for ACORD XML
inbound and outbound messages that pass data between insurance
institutions and other entities and the Insurance Industry Framework. Topics
covered are:
■ ACORD processing flow and architecture
■ ACORD processing rules
■ Building XML rules
■ Adding a new product
■ Sample Messages
ACORD Processing Flow and Architecture

The Framework is designed to receive and process both incoming and
outgoing ACORD XML messages. It integrates with external systems through
a SOAP Service. For this purpose, a separate RuleSet called
PegaInsACORD has been defined. When installed, the framework set up to:
■ Receive an inbound ACORD XML message from an external system

through a SOAP service
■ Parse and map the data from the message to a work object page on the
clipboard
■ Execute a flow that processes the data and calculates the premium and
creates a work object
■ Map the data from the work object page on the clipboard to the XML
outbound response message
■ Send an outbound XML message to an external system using the SOAP

service in ACORD standard format
A diagram of the inbound and outbound message process is shown in Figure

7-1.
Processing ACORD XML Messages 7-3
Figure 7-1. Insurance Framework ACORD Message Processing Diagram

ACORD Processing Rules

This section describes the rules that are used to process messages. Some of
these can be used directly when a new product is defined while others need
to be copied and modified in their respective work class in order to add a new
product to the ACORD Design. All rules are defined in PegaInsACORD
ruleset.
A table is provided for each rule that outlines the:
■ Rule type
■ Name of the Applies To class
■ Description of its role in the processing of the message
■ Modifications needed to extend the rule for deployment

General Rules
General rules are the rules in the ACORD message process configuration
that are reusable in any of products that you may add when extending the
Framework. The general rules are placed in parent classes.
GetACORD SOAP Service
Rule Type Rule-Service-SOAP
Applies To PegaIns-Work
Package MyCoInsureACORD
Description Called when the external system tries to connect to the

Framework using the SOAP service. It creates a page called
requestpage on the clipboard and copies the inbound XML onto
that page. Following that, the ProcessACORDMessage activity is
called in PegaIns-Work-Application to process the message.
Modifications Needed None
Note: The GetACORD Soap Service rule is included with the

Framework and can be used for the processing of all products. It initiates
the ProcessAcordMessage SOAP activity in the PegaIns-Work-
Application class that determines the message type then gets the
respective work class for the ACORD message (for example: PegaIns-
Work-Application-Pers-Automotive). It then calls the
ProcessAcordMessage activity in the respective work class for the
message.
ProcessACORDMessage Activity
Rule Type Rule-Obj-Activity
Applies To PegaIns-Work-Application
Package MyCoInsureACORD
Description Called from the SOAP service to process the ACORD message.
This is the main activity in the ACORD design. It finds the
message type and calls ProductSelection and SetWorkPageClass
decision tables to set the pyWorkPage class and pyLabel. Using
ProductSelection decision table, the message type is set to the
pyLabel property. In the SetWorkPageClass decision table, the
pyLabel is passed as the input property and returns the respective
work class of the product. Next, the ProcessACORDMessage
activity of the work class (Depending on the input message type)
is called to continue the parsing. Finally, the
ProcessACORDMessage flow creates the response message,
calculates the premium and handles the errors. If any errors found
during the validation of the message or processing the message
then it sets the task status to errorsfound. Depending on the
status message, the flow will be executed.
Modifications Needed Include the tag name of the message type (like
PersAutoPolicyQuoteInqRq (for PersonalAuto) and
HomePolicyQuoteInqRq for HomeOwner) in the Java step of the
activity. Append the tag name to the local variable msgTags in
the java step (Instructions to append the string are provided in the
java step).
ProductSelection Decision Table
Rule Type Rule-Declare-DecisionTable
Description Sets the product name to the pyLabel property depending on the
input message type. Include the message type tag and the
product name for the respective tag in this rule.
Modifications Needed Append the tag name and the respective product name for the
product.
SetWorkPageClass Decision Table
Rule Type Rule-Declare-DecisionTable
Description Sets the work class to a local property depending on pyLabel.

Need to include pyLabel and the work class for the respective
product in this rule. It will set the work class dynamically
depending upon the input message type.
Modifications Needed Append the pyLabel and the respective work class for the
product.
ProcessACORDMessage Flow
Rule Type Rule-Obj-Flow
Description Calls the activities for price calculation, handles errors and
creates the appropriate response messages. Respective price
calculation activities will be called from the product, and premium
is calculated
CreateACORDResponse Activity
Description Calls the (Rule-Obj-Xml) QuoteResponse instance for the work

class of the product to set the outbound ACORD message on the
clipboard page.

QuoteResponse XML
Rule Type Rule-Obj-XML

Applies To PegaIns-Work-Application-Pers-Automotive
Description Gets the data from clipboard properties, creates an XML message
and sets the message to a string property on the clipboard. This
rule incorporates some other Rule-Obj-XML rules. In order to set
the clipboard property values, create the Obj-XML rules based on
tthe clipboard structure (see the QuoteResponse instance for the
personal auto product).
Modifications Needed Save this rule into the work class and modify the code
accordingly.
CreateACORDErrorResponse Activity
Description If there are any errors while processing the message, this activity
is invoked. It calls the (Rule-Obj-Xml) QuoteErrorResponse of
particular work class of the product to set the outbound ACORD
message on to the clipboard page to send the error response
data.

QuoteErrorResponse XML
Rule Type Rule-OBJ-XML
Description Gets the data from the clipboard properties, creates an XML
message and sets the message to a string property on the
clipboard. In order to get the clipboard property values, create the
Obj-XML rules according to the clipboard structure (See the
QuoteResponse instance for the personal auto product). This rule
can be invoked if there are any error messages on the clipboard
pages.
Modifications Needed Save this rule into the work class and modify the code
accordingly.
Parsing Rules
These general rules parse the incoming ACORD message and place it on
the clipboard.
SignonRq Parse XML

Rule Type Rule- Parse-XML
Applies To PegaIns-Data-ACORD-SignonRq
Description Parses the Sign on related data from the inbound message onto
the clipboard page SignOnRq
ParseApplicant Activity
Rule Type Rule-OBJ-Activity
Description Gets the chunk of xml from the original xml and calls the parsing
rules to map the applicant details onto the clipboard structure. It
gets the chunk of xml from the original message for the
InsuredOrPrincipal tag and stores the value in a value list. This
rule is a generalized rule; therefore, this can be reusable in all the
products.

ApplicantInfo Parse XML
Rule Type Rule-Parse-XML
Applies To Data-Party
Description Parses the applicant information onto the clipboard structure, if

provided with the chunk of xml
ParseBroker Activity
Description Gets the chunk of xml from original xml and then calls the parsing
rules to map the Broker (producer) details on to the clipboard
structure. It also gets the chunk of xml from the original message
for Producer tag and stores the value in a value list.
MapBroker Parse XML
Applies To Data-Party
Description Parses the Broker information onto the clipboard structure, if

provided with the chunk of xml

Application Specific Rules

The following rules are application-specific. When a product is added to the
Framework, these rules should be copied to the work class of the particular
application and modified to meet your processing needs. The examples in
this section are instances of the rules used to process the personal auto
product.
ProcessACORDMessage Activity
Description This rule belongs to the work class of the product (For example,
the rule referenced here is for the PegaIns-Work-Application-
Pers-Automotive product). Save this rule into each product class.
Rules need to be modified/created in this activity according to the
product design. This activity calls SetupProductData of PegaSP-
Work- to create the clipboard structure of the application. After
that, the ParseMessage activity in the respective work class of the
product is called to parse the message. A Work object is created
by calling the AddWork activity.
Modifications Needed Save this rule into the product work class. Modify the steps
according to the product.
ParseMessage Activity
Description This activity is defined in the work class of the product (eg:
PegaIns-Work-Application-Pers-Automotive). It calls subsequent
activities, browsing the clipboard structure to parse the inbound
XML on to the clipboard properties. All the parsing mechanisms
related to the product are implemented in this activity. Different
Parse-XML rules need to be created according to the clipboard
structure of the product.
Modifications Needed Save this rule into the product work class. Modify the steps
according to the product design and clipboard structure of the
product.
AcordProductOptionData Parse XML
Description Maps the product option data (like plannedenddate and

inceptiondate) onto the clipboard page.
Modifications Needed Save this rule into the product work class. Modify properties
according to the product design and clipboard structure of the
product.
Note: The following activity and parsing rules support the clipboard
structure for processing the personal auto product. These rules provide
good examples to work from when implementing new products but are
not be useful for any other product by simply saving them into another
work class.
ParseAcordGaragingLocations Activity
Applies To Embed-PegaSP-ProductComponents
Description This rule is specified for use in the personal auto product.
Modifications Needed Used in only personal auto. If required can be used in the
commercial auto product.
ParseAcordInsuredPropertyLocation Activity
Applies To PegaIns-Data-PolCmp-InsuredPropertyLocation
Description This rule is specified for use in the personal auto product. For
each optiondata page (Location) this activity is called.
ParseAcordCoveredVehicles Activity
Applies To Embed-PegaSP-ProductComponents
Description This rule is specified for use in the personal auto product. For
each component (CoveredVehicles) page, this activity will be
called. This activity gets the chunk of xml for <persVeh> tag and
appends the values to the value list on the clipboard. If the value
list has more than one value then it will call InsertSubPage
activity of PegaSP-Work- to create one more option data page.
And finally calls the ParseAcordInsuredVehicleData activity for
each option data page
ParseAcordInsuredVehicleData
Applies To PegaIns-Data-PolCmp-InsuredVehicle
Description This rule is specified for use by the personal auto product. For
each Optiondata page (for vehicles) this activity will be called.
This activity gets the chunk of xml for each coverage tag in the
input XML and appends it to the CoverageList on the clipboard. It
will map the vehicle info on to the clipboard as well.
VehicleInfo Parse XML
Description This parse xml will map the vehicle details onto the clipboard
structure, if provided with the chunk of xml for vehicle data.
ParseAcordCoverages Activity
Description Maps the coverage details on to the clipboard structure. It is

called for each element in the coverage list. It determines the
coverage code of and based on coverage code it maps the values
on to the clipboard structure.
Building Rule-Obj-XML rules

This section describes how the Rule-Obj-XML rules used in the process
should be designed and configured as well as how to include and validate
the optional tags into a message.
Note: Rule-Obj-XML rules should be built using JSP tags instead of the
HTML directives option.
■ There are many optional tags that may or may not be included in an
outbound message. According to ACORD standards, an optional tag
should not appear in the message if it does not contain a value (if the
value of tag is blank). To comply with that standard, it is necessary to
add a When rule for each tag to validate if the value of property is blank
before including the tag into the message.
■ All Rule-Obj-XML rules should be based on the clipboard structure, and

embedded into the other XML rules. For a better understanding of this
type of configuration, refer to the QuoteResponse XML rule created for
the Personal Auto Product. Figure 7-2 provides a visual example of how
to include When rules, JSP tags and other Obj-XML rules into an Obj-
XML rule.
Figure 7-2. Sample of Rule Incorporating XML and JSP Features

Adding a New Product

This section describes the design and configuration steps to follow when
ACORD messages for a new product is introduced.
Step 1.
Create sample inbound XML for the product if it is not available. The ACORD
help file is a good reference to use to help create the sample messages.
Step 2.
Update the java step (Desc: Set the tag for inbound message here) in the
ProcessACORDMessage activity in the PegaIns-Work-Application class.
Append the product tag to the local variable msgTags (See
PersAutoPolicyQuoteInqRq and HomePolicyQuoteInqRq for examples). This
is used to find the message type. Follow the instructions mentioned in the
java step to append the tag.
Step 3.
Update the ProductSelection and SetWorkPageClass Decision tables of
PegaIns-Work-Application class to include product name and the work class
for the new product.
Step 4.
Create/Save the ProcessAcordMessage activity in the respective work class
of the ACORD message (For example: PegaIns-Work-Application-Pers-
Automotive). Customize the activity to populate the required product to the
clipboard.
Step 5.
Create/Save the ParseMessage activity in the respective work class of the
ACORD message and call it in the ProcessAcordMessage of the work class.
This activity will bundle all the Parsing rules for the product
Step 6.
Create the Rule-Parse-XML and the activities to call these Rule-Parse-XML
rules by hand to map the request data from the message to the clipboard.
These Parse-XML rules will be bundled in ParseMessage activity. All the
parsing rules should be created by looking into clipboard structure. You will
get an idea by looking into the Personal Auto product.
Rule-Parse-XML rules specific to each product must be created and called

them in the ParseMessage activity.
When there are repeating elements (eg: <PersVeh>) in the message, same
number of corresponding components should be created in the Clipboard.
For that, the PegaSP- Work.InsertSubPage activity is used. Chunk xml
which contains the repeating group of the main xml message is taken to a
value list property (See the ParseAcordCoveredVehicles activity in Embed-
PegaSP-Component class for reference) using the GetXMLElementbyTag
Rule-Utility-Function. Then, for each value in the value list InsertSubPage
activity is called and corresponding component is added to the clipboard.
Step 7.
Call the AddWork activity from the ProcessAcordMessage activity to create
the work object.
Step 8.
Create QuoteResponse and QuoteErrorResponse Rule-Obj-Xml’s in the
respective work class of the product.
Step 9.
After that, do the following:
− Create the Rule-Obj-XML rules by hand to map the response data from
the product’s work page on the clipboard to the xml message. Use JSP
tags instead of using the HTML.
− For each tag that needs to be included in the outbound message, add a
When condition to not to include the tag in outbound message if the
value is blank. These rules should be created according to the clipboard
structure and all rules should be embedded into the QuoteResponse
XML rule of the work class of the product. See QuoteResponse and
QuoteErrorResponse in the Personal Auto Product for reference.
Sample Messages
Sample inbound and outbound XML message formats are included in the
installation media. The message samples are available for:
■ Inbound Request Messages

− Personal Auto Quote
− Home Policy Quote
■ Outbound Response Messages

− Personal Auto Quote
− Home Policy Quote
Appendix A
Database Tables
The Insurance Industry Framework comes with a robust set of industry
standard sample data that simulates the processing environment. You can
use these sample database tables as a starting point for integration or for
demonstrating the system environment.
This appendix includes a list of those database tables that are installed with
the Framework. The following information, where applicable, is included for
each database:
■ Description of the database
■ List of Columns with data type and size
■ Constraints
■ Large object (LOB) storage attributes
■ Foreign key references not defined in the database
■ Referencing tables and columns

A-2 Insurance Industry Framework Implementation Guide
Database Tables
Figure A-1 lists the tables in the database structure. Tables fall into two
categories:
■ The IIF (Insurance Industry Framework) database tables that are specific
to the framework and contain Insurance specific data.
■ The PA (PegaApp) tables that contain party information about Contacts.
Tables and lists beginning on page A-3 provide details, where applicable,
about column structures, constraints, LOB storage, foreign keys, and
referencing tables for each of the tables listed in Figure A-1.
Note: In Oracle, all table data and column headings appear in uppercase
characters, but correct SQL is in lowercase. The Insurance Industry
Framework follows a universal approach and uses lowercase characters.
IIF_Tables
IIF_POLICY IIF_POLICY_LINK
IIF_AGENCY_LOB
PA_ Tables
PA_ADDRESS PA_CONTACT_BUSINESSUNIT_LINK
PA_ADDRESS_TYPE PA_CUSTOMER_TYPE
PA_BUSINESSUNIT PA_INDUSTRY
PA_BUSINESSUNIT_LINK PA_NOTES
PA_COMMUNICATION_OPTIONS PA_PRODUCT
PA_COMMUNICATION_TYPES PA_PRODUCT_TYPE
Figure A-1. List of Tables in the Insurance Industry Framework
Database Tables A-3
IIF_POLICY
This table stores policy specific information. Replace calls to this table with
calls to your external database tables or the interface to the system of record
for your policy data.
Columns
Name Datatype Size Scale Nulls? Dflt
PXCREATEDATETIME DATE 7 Yes
PXCREATEOPNAME VARCHAR2 128 Yes
PXCREATEOPERATOR VARCHAR2 128 Yes
PXCREATESYSTEMID VARCHAR2 32 Yes
PXINSNAME VARCHAR2 128 Yes
PXOBJCLASS VARCHAR2 96 Yes
PXUPDATEDATETIME DATE 7 Yes
PXUPDATEOPNAME VARCHAR2 128 Yes
PXUPDATEOPERATOR VARCHAR2 128 Yes
PXUPDATESYSTEMID VARCHAR2 32 Yes
PYLABEL VARCHAR2 64 Yes
PZINSKEY VARCHAR2 255 No
POLICYID VARCHAR2 20 No
MODNUMBER NUMBER 3 0 No
TRANSACTIONEFFECTIVEDATE DATE 7 No
TRANSACTIONPROCESSDATE DATE 7 No
TRANSACTIONENDDATE DATE 7 Yes

POLICYEFFECTIVEDATE DATE 7 Yes
POLICYENDDATE DATE 7 Yes
POLICY_DESCRIPTION VARCHAR2 50 Yes
POLICYSTATUS VARCHAR2 20 Yes
ACCOUNTPACKAGE VARCHAR2 20 Yes
ACCOUNTTYPE VARCHAR2 20 Yes
ACTIVE VARCHAR2 5 Yes
ADDEDBY VARCHAR2 50 Yes
ADDRESSFROMDATE DATE 7 Yes
ADDRESSLASTCHANGEDATE DATE 7 Yes
ADDRESSLINE1 VARCHAR2 36 Yes
ADDRESSTODATE DATE 7 Yes
ADDRESSUPDATECOUNTER NUMBER 3 0 Yes 0
APPLICATIONTYPE VARCHAR2 20 Yes
BUSINESSPHONE VARCHAR2 20 Yes
BUSINESSUNITID VARCHAR2 20 Yes
CELLPHONE VARCHAR2 17 Yes
CITY VARCHAR2 20 Yes
CONTACTID VARCHAR2 20 Yes
COUNTRYCODE VARCHAR2 20 Yes

Database Tables A-5
CUSTOMERVALUE VARCHAR2 20 Yes
DATEADDED DATE 7 Yes
DATEDELETED DATE 7 Yes
DATEUPDATED DATE 7 Yes
DELETEDBY VARCHAR2 50 Yes
EMAIL VARCHAR2 50 Yes
FAX VARCHAR2 20 Yes
FIRSTNAME VARCHAR2 20 Yes
HOMEPHONE VARCHAR2 17 Yes
LASTNAME VARCHAR2 50 Yes
MIDDLENAME VARCHAR2 20 Yes
PRODUCTID VARCHAR2 32 Yes
ROLEDESCRIPTION VARCHAR2 20 Yes
SECURITYANSWER VARCHAR2 50 Yes
SECURITYQUESTION VARCHAR2 100 Yes
SPECIALINSTRUCTIONS VARCHAR2 100 Yes
STATECODE VARCHAR2 2 Yes
STATEMENTCUTDATE VARCHAR2 2 Yes
UPDATEDBY VARCHAR2 50 Yes
ZIPCODE VARCHAR2 12 Yes
PZPVSTREAM BLOB Yes
POLICYTYPE VARCHAR2 20 Yes

Figure A-2. IIF_POLICY Table Columns
Constraints
Constraint Name SYS_C0014541
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Cascade On Delete No
Check Condition
Deferrable? No
No Validate? No
Initially Deferred? No
RELY (Do Not Enforce)? No

Figure A-3. IIF_POLICY Table Constraints
Constraint Column Details
Table Columns Constraint Referenced Column
POLICYID SYS_C0014541
MODNUMBER
TRANSACTIONEFFECTIVEDATE
TRANSACTIONPROCESSDATE
Figure A-4. IIF_POLICY Constraint Column Details
Database Tables A-7
Large Object (LOB) Storage Attributes
Table Column PZPVSTREAM
Tablespace: USERS
Enable Lob Storage in Row Yes
Number of blocks accessed at 16384 Bytes

one time (CHUNK):
Space used for new version 10 %

(PCTVERSION):
Lob Cache: Off
Generate full redo for LOB data Yes

pages(LOGGING)
Figure A-5. IIF_POLICY Table LOB Attributes
Referencing Tables and Columns
Column Referencing Table Referencing Column
POLICYID IIF_POLICY_LINK POLICYID
MODNUMBER MODNUMBER
TRANSACTIONEFFECTIVEDATE TRANSACTIONEFFECTIVEDATE
TRANSACTIONPROCESSDATE TRANSACTIONPROCESSDATE
Figure A-6. IIF_POLICY Referencing Tables and Columns
IIF_POLICY_LINK
This table maintains the relationship between a contact or business unit, a
policy id and the role that the contact or business unit has with the policy
Columns
PXINDEXCOUNT NUMBER 18 0 Yes
PXINDEXPURPOSE VARCHAR2 32 Yes
PXINSINDEXEDCLASS VARCHAR2 96 Yes
PXINSINDEXEDKEY VARCHAR2 255 Yes
PXPRIVILEGECLASS VARCHAR2 64 Yes
PXPRIVILEGENAME VARCHAR2 256 Yes

Database Tables A-9
PARTYTYPE VARCHAR2 1 Yes
PARTYID VARCHAR2 128 Yes
ROLETYPE VARCHAR2 5 Yes
TRANSACTIONEFFECTIVEDATE DATE 7 Yes
TRANSACTIONPROCESSDATE DATE 7 Yes
TRANSACTIONENDDATE DATE 7 Yes
POLICYTYPE VARCHAR2 20 Yes
POLICYID VARCHAR2 20 Yes
MODNUMBER NUMBER 3 0 Yes
POLICYSTATUS VARCHAR2 20 Yes

Figure A-7. IIF_POLICY_LINK Table Columns
Constraints
Constraint Name POLICYLINK_INDEX_PK
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-8. IIF_POLICY_LINK Table Constraints
Table Columns Constraint Referenced Columns
PZINSKEY POLICYLINK_INDEX_PK
Figure A-9. IIF_POLICY_LINK Constraint Column Details
Database Tables A-11
Foreign Key Relationships
POLICYID IIF_POLICY POLICYID

MODNUMBER MODNUMBER
TRANSACTIONEFFECTIVEDATE TRANSACTIONEFFECTIVEDATE
TRANSACTIONPROCESSDATE TRANSACTIONPROCESSDATE
PARTY ID PA-CONTACT CONTACTID
ROLETYPE PA_ROLES ROLETYPE

Figure A-10. IIF_POLICY_LINK Foreign Key Relationships
IIF_AGENCY_LOB
This table stores the line of business information that an agency is licenses
to write in a given state for a stated period of time.
Columns
AGENCYCODE VARCHAR2 20 No
LINEOFBUSINESS VARCHAR2 30 No
LOBEFFECTIVEDATE DATE 7 No
LOBEXPIRATIONDATE DATE 7 Yes
LICENSEDSTATE VARCHAR2 2 No
COMMISSIONPERCENTAGE VARCHAR2 3 Yes

Figure A-11. IIF_AGENCY_LOB Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-12. IIF_AGENCY_LOB Table Constraints
AGENCYCODE SYS_C0017441
LINEOFBUSINESS
LOBEFFECTIVEDATE
LICENSEDSTATE
Figure A-13. IIF_AGENCY_LOB Constraint Column Details
PA_ADDRESS
This table stores address information about contacts and business units.
Replace calls to this table with calls to your data tables.
Columns
OWNERID VARCHAR2 12 No
ADDRESSID VARCHAR2 1 No
ADDRESSTYPE VARCHAR2 4 No
CITY VARCHAR2 20 Yes
STATECODE VARCHAR2 2 Yes
ZIPCODE VARCHAR2 10 Yes
COUNTRYCODE VARCHAR2 12 Yes
DATEFROM DATE 7 Yes
DATETO DATE 7 Yes
PRIMARYADDRESS VARCHAR2 5 Yes
NOTES VARCHAR2 255 Yes
DATEADDED DATE 7 No

Figure A-14. PA_ADDRESS Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-15. PA_ADDRESS Table Constraints

OWNERID SYS_C0013127
ADDRESSID
ADDRESSTYPE
DATEADDED
Figure A-16. PA_ADDRESS Constraint Column Details

OWNERID PA_CONTACT CONTACTID
OWNERID PA_BUSINESSUNIT BUSINESSUNITID
OWNERID PA_ADDRESS_TYPE BUSINESSUNITID

Figure A-17. PA_ADDRESS Foreign Key Relationships
PA_ADDRESS_TYPE
This table stores the valid address types (for example, HOME or BILLING)
used within the system. Replace the sample entries in this table with address
types valid for your configuration.
Columns
ADDRESSTYPE VARCHAR2 4 No
ADDRESSTYPEDESCRIPTION VARCHAR2 36 No
ADDRESSOUTLOOKCODE VARCHAR2 40 Yes

Figure A-18 .PA_ADDRESS_TYPE Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-19. PA_ADDRESS_TYPE Table Constraints
ADDRESSTYPE SYS_C0013128
Figure A-20. PA_ADDRESS_TYPE Constraint Column Details
ADDRESSTYPE PA_ADDRESS ADDRESSTYPE

Figure A-21. PA_ADDRESS_TYPE Referencing Tables and Columns
PA_BUSINESSUNIT
This table stores information about business units. Replace calls to this table
with calls to your data tables.
Columns
BUSINESSUNITID VARCHAR2 20 No
BUSINESSUNITNAME VARCHAR2 50 No
CUSTOMERTYPE VARCHAR2 15 Yes
PARENT VARCHAR2 12 Yes
INDUSTRYCODE VARCHAR2 15 Yes
PRIORITYTYPE VARCHAR2 36 Yes
TAXID VARCHAR2 12 Yes
WEBSITE VARCHAR2 50 Yes
CUSTOMERLOGO VARCHAR2 50 Yes
REFERENCE VARCHAR2 1 Yes
TERRITORY VARCHAR2 12 Yes
CUSTOMEREMPLOYEE VARCHAR2 12 Yes
PRIMARYADDRESS VARCHAR2 5 Yes
PRIMARYCONTACT VARCHAR2 10 Yes
CUSTOMERSATISFACTION VARCHAR2 20 Yes
BUSINESSDESCRIPTION VARCHAR2 255 Yes
DIVISION VARCHAR2 30 Yes

INTERNALREFERENCE VARCHAR2 30 Yes
PIN VARCHAR2 30 Yes
PRIORITYNOTE VARCHAR2 255 Yes
STATUS VARCHAR2 30 Yes

Figure A-22. PA_BUSINESSUNIT Table Columns
Constraints
Constraint Name SYS_C0013137 SYS_C0013138 SYS_C0013139
Type PRIMARY FOREIGN FOREIGN
Disable No No No
Referenced Schema FRM5102 FRM5102
Referenced Table PA_CUSTOMER_TYPE PA_INDUSTRY
Cascade On Delete No No No
Check Condition
Deferrable? No No No
No Validate? No No No
Initially Deferred? No No No
RELY (Do Not No No No

Enforce)?
Figure A-23. PA_BUSINESSUNIT Table Constraints

Column Constraint Referenced Column
BUSINESSUNITID SYS_C0013137 ADDRESSTYPE
CUSTOMERTYPE SYS_C0013138 CUSTOMERTYPE
INDUSTRYCODE SYS_C0013139 INDUSTRYCODE

Figure A-24. PA_BUSINESSUNIT Constraint Column Details
BUSINESSUNITID PA_CONTACT_BUSINESSUNIT_LINK BUSINESSUNITID
BUSINESSUNITID PA_ADDRESS OWNERID

Figure A-25. PA_BUSINESSUNIT Referencing Tables and Columns
PA_BUSINESSUNIT_LINK
This table stores business-to-business relationships. For example, it shows
that Acme Technology is a subsidiary of Acme Software.
Columns
BUSINESSUNIT1 VARCHAR2 20 No
BUSINESSUNIT2 VARCHAR2 20 No
TYPE VARCHAR2 50 No
DESCRIPTION VARCHAR2 100 Yes
MEMO VARCHAR2 255 Yes
DATEADDED DATE 7 No

Figure A-26. PA_BUSINESSUNIT_LINK Table Columns
Constraints
Constraint Name SYS_C0013140 SYS_C0013141
Type PRIMARY FOREIGN
Disable No No
Referenced
FRM5102
Schema
Referenced Table PA_BUSINESSUNIT
Cascade On Delete No No
Check Condition
Deferrable? No No
No Validate? No No
Initially Deferred? No No
RELY (Do Not No No

Enforce)?
Figure A-27. PA_BUSINESSUNIT_LINK Table Constraints

BUSINESSUNIT1 SYS_C0013140 ADDRESSTYPE

BUSINESSUNIT2
TYPE
DATADDED
BUSINESSUNIT1 SYS_C0013141 BUSINESSUNITID

Figure A-28. PA_BUSINESSUNIT_LINK Constraint Column Details
PA_COMMUNICATION_OPTIONS
This table stores communication information for contacts and business units.
Replace calls to this table with calls to your data tables.
Columns
OWNERID VARCHAR2 12 No
COMMUNICATIONID VARCHAR2 1 No
COMMUNICATIONTYPE VARCHAR2 10 No
ADDRESSTYPE VARCHAR2 10 Yes
PRIMARYCOMMUNICATION VARCHAR2 5 Yes
CONTACTSTRING VARCHAR2 255 Yes
DATEADDED DATE 7 No
DATEFROM DATE 7 Yes
DATETO DATE 7 Yes

Figure A-29. PA_COMMUNICATION_OPTIONS Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No
RELY (Do Not No

Enforce)?
Figure A-30. PA_COMMUNICATION_OPTIONS Table Constraints

BUSINESSUNITID SYS_C0013129
COMMUNICATIONID
COMMUNICATIONTYPE
DATEADDED
Figure A-31. PA_CMMUNICATION_OPTIONS Constraint Column Details
OWNERID PA_CONTACT CONTACTID
COMMUNICATIONTYPE PA_COMMUNICATION_TYPES TYPE

Figure A-32. PA_COMMUNICATION_OPTIONS Foreign Key Relationships
PA_COMMUNICATION_TYPES
This table stores the valid communication types (for example, HOME-EMAIL
or HOME-PHONE) used within the system. Replace the sample entries in
this table with communication types valid for your configuration.
Columns
Name Datatype Size Scale Nulls?
TYPE VARCHAR2 10 No
DESCRIPTION VARCHAR2 25 Yes
CATEGORY VARCHAR2 1 Yes
CLASS VARCHAR2 10 Yes

Figure A-33. PA_COMMUNICATION_TYPES Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No
RELY (Do Not No

Enforce)?
Figure A-34. PA_COMMUNICATION_TYPES Table Constraints

TYPE SYS_C0013130
Figure A-35. PA_COMMUNICATION_TYPES Constraint Column Details
TYPE PA_COMMUNIATION_OPTIONS COMMUNICATIONTYPE

Figure A-36. PA_COMMUNICATION_OPTIONS Foreign Key Relationships
PA_CONTACT
This table is a sample table that stores information about contacts. Replace
calls to this table with calls to your data tables.
Columns
CONTACTID VARCHAR2 12 No
CUSTOMERTYPE VARCHAR2 15 Yes
SOCIALSECURITYNUMBER VARCHAR2 9 Yes
LASTNAME VARCHAR2 50 No
FIRSTNAME VARCHAR2 36 Yes
MIDDLENAME VARCHAR2 36 Yes
SALUTATION VARCHAR2 12 Yes
SUFFIX VARCHAR2 5 Yes
SHORTNAME VARCHAR2 20 Yes
DATEOFBIRTH DATE 7 Yes
DATEOFDEATH DATE 7 Yes
MARITALSTATUS VARCHAR2 10 Yes
LANGUAGE VARCHAR2 18 Yes
PIN VARCHAR2 30 Yes
MOTHERMAIDENNAME VARCHAR2 50 Yes
TERRITORYID VARCHAR2 12 Yes
PRIORITYTYPE VARCHAR2 36 Yes
WEBPRIVILEGES VARCHAR2 1 Yes
LOGINS NUMBER 10 0 No 0
BADLOGINS NUMBER 10 0 No 0
DATEOFLASTLOGIN DATE 7 Yes
NICKNAME VARCHAR2 26 Yes
BUSINESSAFFILIATION VARCHAR2 12 Yes
GENDER VARCHAR2 1 Yes
SECURITYQUESTION VARCHAR2 100 Yes
SECURITYANSWER VARCHAR2 50 Yes
COMMUNICATIONPREFERENCE VARCHAR2 10 Yes
PRIORITYNOTE VARCHAR2 255 Yes
CUSTOMERVALUE VARCHAR2 30 Yes
BESTTIMETOCALL VARCHAR2 20 Yes
NOMARKETINGBYMAIL VARCHAR2 5 Yes
NOMARKETINGBYPHONE VARCHAR2 5 Yes
NOMARKETINGBYEMAIL VARCHAR2 5 Yes
COMPANY VARCHAR2 50 Yes
OCCUPATION VARCHAR2 50 Yes
Figure A-37. PA_CONTACT Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-38.PA_CONTACT Table Constraints
CONTACTID SYS_C0013131
Figure A-39. PA_CONTACT Constraint Column Details
CUSTOMERTYPE PA_CUSTOMER_TYPE CUSTOMERTYPE

Figure A-40. PA_CONTACT Foreign Key Relationships
CONTACTID PA_ADDRESS OWNERID
CONTACTID PA_CONTACT_BUSINESSUNIT_LINK CONTACTID
CONTACTID IIF_POLICY_LINK PARTYID
CONTACTID PA_COMMUNICATIONS_OPTIONS OWNERID

Figure A-41. PA_CONTACT Referencing Tables and Columns
PA_CONTACT_BUSINESSUNIT_LINK
This table stores contact-to-business relationships. For example, Jeff Buten
is associated with Buten Bearings as an authorized party.
Columns
CONTACTID VARCHAR2 12 No
BUSINESSUNITID VARCHAR2 20 No
TYPE VARCHAR2 50 No
PRIMARYASSOCIATION VARCHAR2 1 Yes
DATEADDED DATE 7 No

Figure A-42. PA_CONTACT_BUSINESSUNIT_LINK Database Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-43.PA_CONTAC_BUSINESSUNIT_LINK Table Constraints
CONTACTID SYS_C0013134
BUSINESSUNITID
TYPE
DATEADDED
Figure A-44. PA_CONTACT_BUSINESSUNIT_LINK Constraint Column Details
CONTACTID PA_CONTACT CONTACTID
BUSINESSUNITID PA_BUSINESS_UNIT BUSINESSUNITID

Figure A-45. PA_CONTACT_BUSINESSUNIT_LINK Foreign Key Relationships
PA_CUSTOMER_TYPE
This table stores the information used to describe the business unit as a
particular type of customer. Examples of customer type values are Fortune
500, Small Business, and Partnership.
Columns
CUSTOMERTYPE VARCHAR2 15 No
CUSTOMERTYPEDESCRIPTION VARCHAR2 100 Yes

Figure A-46. PA_CUSTOMER_TYPE Table Columns
Constraints
Constraint Name SYS C0013132
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-47. PA_CUSTOMER_TYPE Table Constraints
CUSTOMERTYPE SYS_C0013132
MODNUMBER
TRANSACTIONEFFECTIVEDATE
TRANSACTIONPROCESSDATE
Figure A-48. PA_CUSTOMER_TYPE Constraint Column Details
CUSTOMERTYPE PA_CONTACT CUSTOMERTYPE
CUSTOMERTYPE PA_BUSINESSUNIT CUSTOMERTYPE

Figure A-49. PA_CUSTOMER_TYPE Referencing Tables and Columns
PA_INDUSTRY
This table stores information that describes the industry in which a business
operates. Examples of industry values are Healthcare, Insurance, and
Technology.
Columns
INDUSTRYCODE VARCHAR2 15 No
INDUSTRYDESCRIPTION VARCHAR2 36 Yes

Figure A-50. PA_INDUSTRY Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-51. PA_INDUSTRY Table Constraints
INDUSTRYCODE SYS_C0013133
Figure A-52. PA_INDUSTRY Constraint Column Details
INDUSTRYCODE PA_BUSINESSUNIT INDUSTRYCODE

Figure A-53. PA_INDUSTRY Referencing Tables and Columns
PA_NOTES
This table stores ad-hoc notes that are added to contact or policy records. It
is provided with the PegaApp layer, but currently is not used by the
Insurance Framework.
Columns
NOTEID NUMBER 10 0 No
NOTEDATE DATE 7 No
ACCOUNTNUMBER VARCHAR2 20 Yes
BUSINESSUNITID VARCHAR2 12 Yes
CONTACTID VARCHAR2 12 Yes
LABEL VARCHAR2 50 Yes
TAKENBYID VARCHAR2 32 Yes
OPPORTUNITYID VARCHAR2 12 Yes
TYPE VARCHAR2 10 Yes

Figure A-54. PA_NOTES Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-55. PA_NOTES Table Constraints
NOTEID SYS_C0013135
Figure A-56. PA_NOTES Constraint Column Details
PA_PRODUCT
This table stores product information. It is provided in the PegaApp layer and
is not currently used in the Insurance Framework.
Columns
PRODUCTCOST NUMBER 19 2 Yes
PRODUCTDESCRIPTION VARCHAR2 100 Yes
PRODUCTID VARCHAR2 32 Yes
PRODUCTLISTPRICE NUMBER 19 2 Yes
PRODUCTNAME VARCHAR2 64 Yes
PRODUCTTYPE VARCHAR2 15 Yes

PZPVSTREAM BLOB Yes

Figure A-57. PA_PRODUCT Table Columns
Constraints
Constraint Name PR_PRODUCT_PK
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-58. PA_PRODUCT Table Constraints
PZINSKEY PA_PRODUCT_PK
Figure A-59. PA_PRODUCT Constraint Column Details
PA_PRODUCT_TYPE
This table stores information about the product type. It is provided in the
PegaApp layer and is currently not used by the Insurance Framework.
Columns
ACCOUNTCLASS VARCHAR2 64 Yes
OPPORTUNITYCLASS VARCHAR2 64 Yes
PRODUCTTYPE VARCHAR2 15 Yes
PRODUCTTYPEDESCRIPTION VARCHAR2 50 Yes
SPECIALPRODUCTID VARCHAR2 12 Yes

PZPVSTREAM BLOB Yes

Figure A-60. PA_PRODUCT_TYPE Table Columns
Constraints
Constraint Name PA_PRODUCT_TYPE_PK
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-61. PA_PRODUCT_TYPE Table Constraints
PZINSKEY PA_PRODUCT_TYPE_PK
Figure A-62. PA_PRODUCT_TYPE Constraint Column Details
PA_ROLES
This table stores roles for policy, contact, and business unit links. Some
workflows use the role type to determine processing steps. Add your own
affiliations for account, contact, and business unit associations.
Columns
ROLETYPE VARCHAR2 5 No
PARTYTYPE VARCHAR2 1 Yes
APPLICATION VARCHAR2 10 Yes
ROLEDESCRIPTION VARCHAR2 36 Yes

Figure A-63. PA_ROLES Table Columns
Constraints
Type PRIMARY
Disable No
Referenced Schema
Referenced Table
Check Condition
Deferrable? No
No Validate? No

Figure A-64. PA_ROLES Table Constraints
ROLETYPE SYS_C0013126
Figure A-65. PA_ROLES Constraint Column Details
ROLETYPE IIF_POLICY_LINK ROLETYPE

Figure A-66. PA_ROLES Referencing Tables and Columns

IIF ImpGuide V33

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

IIF ImpGuide V33

Enviado por

Direitos autorais:

Formatos disponíveis

Insurance Industry Framework

This document is the property of:

Insurance Industry Framework

Software Version: 3.3

Updated: June 2008

PegaIns-Interface-Contact ....................................................................................... 3-8

Sample Agent and Agency Data ............................................................................ 4-45

Database Tables ............................................................................................................. A-2

PA_CONTACT .............................................................................................................. A-31

■ PegaRULES Process Commander (Process Commander) is already installed

■ You have taken the appropriate training courses

■ Some team members are PegaRULES Process Commander certified

■ Some team members have business expertise at a detailed level in the

■ Some team members understand the application and technology architecture

What Is the Insurance Industry Framework?

■ An insurance foundation that provides comprehensive partially attributed

■ Starter Kits in three areas (Product Management, Acquiring and Retaining

Insurance Industry Framework

■ Provides a foundation that services a range of business process

■ Provides the ability to define Product Specifications used to create and

■ Enables circumstancing on date and jurisdiction on all relevant business

■ Provides sample User Interfaces to enter basic product specifications, and

■ Provides best-practice sample definitions of insurance parties, commonly

■ Provides full support for the reuse of common product components,

Understanding the Insurance Product

Following is a short description of some sample Insurance products that have

The Insurance Industry Framework, leveraging the imbedded Product

An insurance product may be specified to be a packaging of other products.

Examples of product specifications, class structures, and workflows in the

■ Personal Lines Auto

■ Personal Lines Homeowners

■ Commercial Lines BOP (Business Owner’s Package)

■ Commercial Lines Auto

■ Variable Universal Life

■ Insured objects (risk units)

■ Terms and conditions

■ Services and fees.

Components may consist of other components (subcomponents). All

A “where-used” capability is provided to assist with maintenance and

Your Framework and Process Commander

Figure 1-1. Process Commander Frameworks Showing Layers

Because Pegasystems Frameworks all share the same underlying technology,

Who Should Read This Document?

■ Business Managers — responsible for evaluating the Framework solution

■ Project Managers / Business Analysts — responsible for implementing a

■ System Architects / Application Developers — responsible for building,

■ System and Database Administrators — responsible for the installation,

Education and Training

For more information about Pegasystems programs and schedules, visit us at

Other Information to Read

Documenting Your Application

The Application menu provides access to information about your

■ Document Button — to produce a Microsoft Word document listing all

■ Inventory Button — to produce an interactive HTML report that lists all

1. Click the Process Slice icon.

2. Open one of the flow rules.

3. Click the related rules toolbar button.

4. Choose Flow Explorer for the flow. You can:

■ Check By Description? to view the short description text within the

■ Adjust the levels to determine how many levels are presented.

Creating a New RuleSet

To create a new RuleSet: