In order to achieve your business usecase, I would like to suggest three approaches (pseudocode) and you could prefer one of them: 1. Make use of direct relationships between processes and database: If you have a relationship between the processes and the database you could easily make a query on the database entity. That is, you should be in a position to identify the data associated with a process. Let's corelate this scenario with a example: Let's say a process creates claims (In your case it is cons!PPLM_CUSIP_FEE_RECORD). And in each process we are updating the corresponding claim on need basis and let's call it as claims history (In you case it is amendementRequest_Info). Now let's assume that your database is setup in this manner: claims ------ claims_id process_id 1 001 2 002 3 003 claims_history -------------- claims_history_id claims_id created_by modified_by 1 1 x 2 2 y 3 1 x 4 1 x Also if we think of processes in Appian, each claims process contains claims_history which is a multiple cdt Now if I query the claims processes by making use of the a!queryAnalytics(), let's assume that I got two process ids namely 001 and 002. It's a cake walk for us to create a query rule which gets us the claims_history which could be as follows: select * from claims_history where claims_id in (select claims_id from claims where process_id in ()) Now convert the data to datasubset and pass the same to the SAIL grid component. This is the most easiest as well as efficient way to get the things done. But I agree that this kind of database setup may not be done until and unless we come across a usecase. 2. Manage with processes and database by establishing relationships indirectly(Assuming that details in PV are saved in database every time): As you know that you can't make use of cdts or multiple cdts as column in the report you need to opt for a work around where you can read the data from database by indirectly establishing a relationship between process ids and database. Here are the steps which you should opt for doing so: a. Create a report on the processes that makes use of the process model as identified in cons!PPLM_CUSIP_FEE_RECORD record type. In this report create two columns namely as follows: >> processId (value:pp!id, type:Number) >> cusipFeeRecordId (value:pv!cusipFeeRecord.id, type:Number) (Assuming that this process variable of cons!PPLM_CUSIP_FEE_RECORD cdt and id is the primary key) b. By making use of query analytics functions, query the report created in the above step and get all the ids of cons!PPLM_CUSIP_FEE_RECORD. c. Now make a query rule to the database and obtain amendementRequest_Info by making use of the primary keys in your hand. Pass the data to the SAIL grid component. 3. Manage without database (Assuming that details in PV aren't saved in database every time and you are only relying on PVs): As you know that you can't make use of cdts or multiple cdts as column in the report you need to opt for a work around where you can read the data in other formats and cast it back to cdt later. Here are the steps which you should opt for doing so: a. Create a report on the processes that makes use of the process model as identified in cons!PPLM_CUSIP_FEE_RECORD record type. In this report create two columns namely as follows: >> processId (value:pp!id, type:Number) >> externalised_amendementRequest_Info (value:externalize(pv!cusipFeeRecord.amendementRequest_Info), type:Text) (Assuming that this process variable of cons!PPLM_CUSIP_FEE_RECORD cdt) b. By making use of query analytics functions, query the report created in the above step and obtain the values of externalised_amendementRequest_Info column. c. Now internalise the data (i.e. cast the text data to cdt type data) obtained in the above as follows: with( local!text_amendementRequest_Info: ; local!cdt_amendementRequest_Info:apply(fn!internalize(_,null),local!text_amendementRequest_Info), local!cdt_amendementRequest_Info ) d. Convert the output of above to dataubset and use it in grid SAIL component.