Constellation + Common Application (Greenfield Mortgage) – Embedded Applicants/Property vs Contact Entity (CDM) – Recommended Approach?

User Experience
1

Hi All,

I’m building a new greenfield Mortgage Origination application using Pega Constellation, and my application is built on top of Pega Common Application / Common Data Model (CDM).

While creating my first case type and defining the data model, I want to follow the best-practice approach for capturing mortgage application details.

Requirement

In my Mortgage Application case type, I need to capture and store the following information within the case:

  1. Applicants (Embedded PageList)

  • Capture multiple applicants (Primary + Co-applicant)

  • Each applicant should include:

    • Personal details

    • Employment details (may have multiple employments)

    • Income details (may have multiple income sources)

    • Outgoings / commitments

  1. Property (Embedded Page)

  • Capture property details for the mortgage application

  • Property is not linked to an individual applicant

  • Property is common/shared for both applicant

  1. Some additional data model

Questions / Guidance Needed

  1. Should I create these embedded data objects (Applicant / Property) in my implementation layer as embedded pages (Page / PageList) and store them in the case?

  2. Should I use the Contact entity from Common Application / CDM to represent applicants instead of creating my own embedded Applicant structure?

  3. What is the recommended approach for Constellation mortgage applications:

  • Use CDM Contact entity only

  • Create my own embedded Applicant & Property data objects

  • Follow a Hybrid approach (embedded applicant pages + link to Contact entity using ContactID)

  1. Where should I build the views (UI) for these objects?

  • In Common Data Model / Common Application classes

  • Or in my implementation layer classes (Mortgage case class + embedded data object classes)

I’m looking for expert recommendations / best practices for modeling Applicants & Property in a Constellation-based Mortgage application built on Common Application.

Thanks in advance!

2

@Arunkum@r To provide elaborate answers to your questions I have following queries that needs to be understood first

  1. Are you building your implementation on any of Strategic application such as Customer Service ?
  2. What would be the end state for Applicants and Property Data i.e. Data would be stored in system of records or would remain in mortgage application case?
3

@taler

Please find my answers:

  1. No strategic application is used. I am building it on the Common-FS application.

  2. For now, the data is stored only in the case. However, in the future it might be stored in the Pega System of Record (SOR), or we may search an external SOR via API to retrieve full customer details.

4

@Arunkum@r Thanks for providing details. Below are my thoughts on questions you asked.

  1. You should think of using embedded data if data to be captured and stored inside case without need of the data be shared as a master value outside the case i.e. shared “Applicant” or “Property” records across multiple cases.
  2. As you have mentioned the futuristic scope of storing data as Pega System of Records or external SOR . Referencing the data might be beneficial from futuristic usage perspective. i.e. You “Applicant” is an individual which is nothing but Contact entity and "Property" can be ( or-Specialised version of ) Asset entity. You can have references to these entities in your case types. You can choose to use this pattern from usage and data sourcing flexibility perspective
  3. Answer to your 3rd question lies in first two, it’s just that you can choose to use CDM classes as embedded objects or reference. But again the choice should be made between embedding the data vs referring the data based on use cases like storage needs, volume of data , data sharing needs, relationships( like Property can be shared between two individuals i.e. Property (Asset entity) is related to two applicants or individuals (Contact entity)).
  4. Building views would depend on the context classes ( i.e. Implementation classes) like building read only composites or forms in your case type by using “embedded pages” or “Case / data references” to entities.