We have a requirement that we are receiving List of Customer details. And, under each customer page, it contains another page lists containing current customer’s Shipping Address list and Billing Address List.
In UI display:
Table1: Radio select button, Customer ID and Customer Name (List)
Table 2: Shipping Address details (List)
Table 3: Billing Address Details (List) Requirement:
Whenever user Selects any customer (in Table 1), its respective Shipping Address List & Billing Address List should be visible in Table 2&3 respectively.
Additionally, In Table 2 and Table 3, user should be able to select which Address user wants to select.
Also, there should be an “Add“ button in Table2&3, so user should be able to add new Address if required.
Problem:
For 1, how can we retrive and change Address details in Table 2 &3 based on Table 1 selection.
For #2 & 3, It seems to be the combination of Data Reference & Embedded Data functionality, where we need to show existing data, among which user can “select” as well as user needs to have the ability to add new records as well in both tables.
How can we achieve this behavior in PEGA Constellation 25.
I think this can be achieved easily with a small design change. Instead of showing three tables in a screen, if we can show the list of customers and then edit the customer in a modal dialogue, there we can add the tables and select or add addresses.
It’s true that with the combination of Data reference and Embedded tables powered by extension of pyRefreshData you can achieve your requirement.
However, this would be a complex implementation which is hard to maintain in future if any OOTB features change or new requirements are added by upcoming developers.
It obviously feels that you are in control of the data entry all at once place, but there is a limitation with the above approach that you can add new entries only with Inline editing. If you go for Modal dialog, you would hit the wall.
So having said all the above, the approach mentioned by @VVNagaSaiN is a pretty strong approach where you can multi-level modal dialogs to add new addresses, change your shipping and billing addresses without any hassle of maintaining UI screens or data structure.
The UI approach is different but that’s a better way of putting things in my opinion.
There are options to achieving this outcome, as well. I outlined some of this in a post yesterday, but will summarise.
List view/Insights they give you a little more flexibility, both List Views and Insights can do multiple levels of groupings, which can turn flat data into something more hierarchical (as mentioned above)
These “report” options, have added benefits like searching and personalised views, which give flexibility to users depending on the “why” behind the need to show so many addresses and so many levels all at once (can get confusing)
Preview You can use various options, along with Preview, to show a lot more data about each level. So depending on the “why” this might be a preferrable business outcome, it would work much the same as this example.
Thank you for taking your time and providing the valuable insight. But I believe it will not satisfy our exact requirement with this approach:
User should be able to only select from one Customer Details. Because in our requirement we need to save customer ID and it’s related Shipping and Billing Address that user has selected for this customer. (Only one customer and its related details should be saved.)
With this approach, I believe we will have trouble identifying which customer details (and its related Addresses) user has selected if user have the option to update other row details as well.
User should not be allowed to edit existing Address details.
Still Thank you again. I will try this approach one and check if we can achieve anything close to our requirement.
Hi Marc, Thank you for the explanation but i dont think this will satisfy our requirement because:
Our Requirement is not showing tables in hierarchical way. But separate tables but Table 2 and 3 data will be displayed based on the Table 1 details user has selected (for example: If row2 details in Table 1 is the then Table 2&3 should fetch details from Pagelist with row 2 customer ID and display related Addresses.)
Also, User should be able to select only single record of Customer ID (and only 1 Shipping & Billing Address from the Table2 & Table 3 List).
Note: The data on table 2 & 3 will change based on table 1 selection.
As we need to save the details user has selected from this List. I kindly request you to Please suggest any other alternative that will satisfy this requirement.
@RAHULK0923 If you need to limit to a single customer, we can user data reference field for customer selection and couple of embedded data list fields for displaying and adding to list of Existing Shipping and Billing Addresses and couple of Embedded data single fields for Selecting Shipping Address and Billing Address.
Configure Form refresh settings to populate addresses corresponding to that customer whenever customer selection changes.
@RAHULK0923 if you have very specific UI requirements, you may want to consider building your own DX Components. This would give you far greater control to implement specific UI requirements.
Obviously, this would be additional effort, so the client would have to consider the cost/benefit of doing so.
Hi @VVNagaSaiN , Thank you for your quick response.
The first technical issue we are facing with this approach is in First step for Table 1.
We are getting the list from 3rd system party and storing the list in a Page-List. So, as this data is from 3rd party system, so we are not getting the radio button option in Table 1 for selection.
Can you please suggest any alternate approach for this if possible. Thanking you in advance.
@RAHULK0923 Have a look at the above content once where you can configure an external data source like in your case to a data reference field. To summarize, your list data page of your data type should return list of customers sourced from connector and in your default look up data page, modify the source to data transform, take param as the unique customer id you have and in the source data transform, write logic to map the data just related to that single customer by reusing your connector data page here.
You need to do those steps because your data reference field requires both default list data page and look up data page configured correctly for it to work properly.
I did not personally try this, but I remember someone did it in this way. Try it and let us know it it doesn’t work. I will try to implement similar requirement when I find some time.
@RAHULK0923 - upon selection of the shipping and billing, what needs to be stored on the case? Just the id of the address records from the external systems? Or the full address?
I would consider pursuing what VV is suggesting above, if I understand the proposal correctly. Create a mapping layer on the data object so you can do the selection on the UI, then store whatever data you need to on the case. It is sort of like using the data virtualization layer to map to Int- classes, like in the old days.
HI, after user has selected we need to store everything. Customer ID, Customer Name, Full Shipping and Billing Address (Address 1/2/3, City, State, Zip, Country) along with respective Shipping and Billing ID’s. (each ID’s are unique)
First, for dropdown (Data-Reference) as well we need the data to be present locally. But we are getting list from 3rd party system and storing it in Page-List.
Second, we had previously pitched this dropdown idea to our client but they declined this approach.
@RAHULK0923 data references can be sourced externally, they don’t need to be Pega SOR. I saw you were using queries to retrieve data but that is the wrong pattern if you want to select from a list (its usually read only). Data references allows you to select on or more records from the list.
As for your use case, reading back on this, it sounds like you want this?
This is pretty close to @RameshSangili’s suggestion, though I went for 3 data references and 2 embedded data in my data model. I also snuck a “add new address” result into the list, so that it would smooth the UX out, so I didn’t need another table/button/link to switch contexts to add a new address (same data model, just using visibility conditions to show the embedded data to capture new address)
As per our last discussion, we changed the class to concrete manually and compared the rules that gets created automatically using wizard. Everything on high level seems same but nothing changed.
So, as per your suggestion we are posting it here to see if any experts have faced similar issue. Thank you.
Ah. so your question to the community is if anyone has successfully refactor Abstract to Concrete class and used it in Constellation? Given that Abstract Classes have varied support
I took a step back and built a quick Data Reference (selecting data) vs. Embedded data (supplying data) experience (like Amazon ‘Use Another Shipping Address’), a little different take providing shipping data, breaking out the shipping and billing steps to highlight the difference between data reference configuration options and embedded configuration options. A more detailed walkthrough, with instruction, is here.
