Is there any way to retrieve the fields of CDT and store in a variable (multiple

index(ri!cdt, "EmpId", {}) or ri!cdt.EmpId should do it.

Hi Amit, I have one approach - tested and it works.
Use the following expression:

fn!split(fn!stripwith(fn!tostring(type!CDT_NAME()) , "=[]"),",")

where CDT_NAME is the name of your CDT - like Employee_CDT.
This will return you a list of text - each element in the list will be a field in the CDT.

If your CDT contains field called EmpId, EmpName, DOJ - all those names will be returned in a list of text.

Thanks Chetan. It's working.

@amit

Yes we can do it . Call a queryentity to a particular table if CDT is mapped to database or pass the Cdt into interface rule of anytype

Scenario 1:(cdt has duplicate values but I need take unique and show in dropdown)

To do so use queryentity and fetch the data and store it in a local variable. Using union or intersection function u can pick the unique values. And now in dropdown field you can use like the below

choiceLabels:local!variable
choice Value:local!variable

Scenario2 :(subset or cry itself has unique data)
This is something straight forward and you can fetch data and store in a local variable. Pass that local variable as said above

Hope this helps ...!!!

@amit

Yes we can do it . Call a queryentity to a particular table if CDT is mapped to database or pass the Cdt into interface rule of anytype

Scenario 1:(cdt has duplicate values but I need take unique and show in dropdown)

To do so use queryentity and fetch the data and store it in a local variable. Using union or intersection function u can pick the unique values. And now in dropdown field you can use like the below

choiceLabels:local!variable
choice Value:local!variable

Scenario2 :(subset or cry itself has unique data)
This is something straight forward and you can fetch data and store in a local variable. Pass that local variable as said above

Hope this helps ...!!!

@chetany instead of using "=[]" you should use "=[] ". This will eliminate leading spaces in the field names

@joshl, correct. I agree with you.