We wanted to capture the customer information on a landing page and decide whether any case type to be invoked or else ignore capturing the information this is to avoid creating unnecessary cases in Pega with no use if the requested information doesn’t satisfy for case creation.
I am not able to see an option to define a single page type form view. Is this the limitation on Pega constellation 24
In Constellation, Landing Pages are primarily designed to host List Views, Insights, Widgets, and dashboards, rather than standalone Form Views for data capture. While Form Views are intended to be used within the context of a Case or Assignment, Landing Pages focus on presenting and searching information
Hi @RaghunathaB17832311 ,
If the Customer information is as data object, You use the list page template to display a list of data objects. The list page allows you to edit, add, and reorder cases, as well as create, edit, and delete data records.
Refer : Constellation landing pages | Pega Academy
@RaghunathaB17832311 Create a Page property in work class containing the respective data class in page context. use this property as embedded data field in any view and mention it as single page in the view you have created and u should be able to add the properties from customer class as in pyWorkPage.CustomerInfo.CustomerID
You could just create a case? There is a case launcher widget which improves the UX so that it isn’t from the “create menu”.
If the case shouldn’t continue, just cancel it during the create stage. If you’re worried about these cases piling up you could run an archive on these more frequently. if you set a certain state, then you could target just these to archive.
@MarcCheong
We don’t want to capture and store customer information if the case creation is not required, the approach as you mentioned is creating the database insertion and later archiving or deleting it is not we are looking for. As per the compliance as well those customers information cannot be stored in this DB.
We are looking for a form view which decides us to proceed further for the case creation else discard the form.
Pega constellation has this limitations it looks like forcing the client to insert into DB and next archive or delete from the DB. Which is not solving the actual client problem but creating more problems and later fixing.
This is from the list view where you want the data population to the case, we are not looking for this scenario, looking for form view
@RaghunathaB17832311 “We are looking for a form view which decides us to proceed further for the case creation else discard the form.” - This, to me, sounds like the capturing of the customer details should really be the first step in the case you decide to create/not create. Since you mention “…capture the customer information on a landing page”, this sounds like you do not have any record to perform an action on, but rather you enter data which business rules then decide if said data warrants to continue or not. Which is a great example of a workflow starting assignment. You can still wipe the customer data from the case after that assignment if you aren’t allowed to save it.
The idea of the landing page is just a starting assignment moved to another location.
We can achieve of erasing the captured information on the first screen if case creation is not required, but has already created the case with ID as well generated so many operations done in background which is not necessary, after sometime, there will be rejected cases unnecessary in the DB and it would be difficult to identify what is the actual rejected case. We can differentiate the status, but don’t want to overhead the DB with unnecessary data, I feel this is limitation and forcing the clients to create a case even thought it is not necessary which is a limitation.
@RaghunathaB17832311 I still feel like you are describing the perfect candidate for a workflow. Only a case will get you auditability and a history of what actually happened. Saving “true rejected cases” as you mention, would anyway need a case even if you started out with a landing page. Feel free to get in touch with me privately if you want to discuss it further.
@LantzAndreas
Agree to you, if we capture the information on the case and based on the audit we can get what action was taken, what values were updated and by whom .
But our scenario was not to capture and destroy the data or the case if it is not required at all. It will be a negative on the product if it is not supporting what client wants as it has limitations, we used this data first approach feature in Theme Cosmos in earlier project, not form the table list to create the case.
The landing page where it collects the information and based on the Ferry availability creates the case and else data will not be stored.
It looks like Pega wants the case type to be used even it is not necessary.
@RaghunathaB17832311 landing pages are not designed to do this. Cases are used for processing, Data can have Create/Read/Update actions against them.
In a stateless UI, everything has to exist. IF you want to achieve such an outcome you’d need to create a Custom DX Component that stores this transitory information and then calls the create case (if needed).
In that you’d have to handle things that Pega natively handles - business rules, views, auto-saving, validation, error handling etc. It’s not the most advisable approach but is possible.
@MarcCheong : I feel it is a drawback to the Pega constellation if they don’t provide these functionalities, is there any upcoming release where Pega constellation introduces this component as if we create custom component then we need to maintain.
I feel these types of requirements will really hurt the developers or clients as it requires other React component developers.
In other Java bound applications for the stateless applications these scenarios are handled around 15+ years ago with the MVC architecture, now Pega adopts.
Technically, the data instance first approach can be done here as well if you have the Landing Page configured with CURD operator the data tables. You can technically add/modify/delete the records from the Landing Page. I think the scenario is possible through the Landing Page with Data table -In the Landing Page, > Add a new record > Check if there are availability dates based on your selection.. if the list return empty, then cancel the modal dialog for new record.
We initially saw that option as well, but it has the drawback after adding the record, the user need to search for that particular record and later either delete or create a case, another task to the user if there are more number of records, not a great UX 
Also for future cleaning of these PII data it requires to clean at both the places one at the data instances, second on the case data(for any compliance rules)