with reference to my earlier posts

...l as the context report and made include SPs as Yes
2.and In the value of EMP ID column I changed the value to employeeDetails_cdt[1].empID
3.Now the values started coming for all the values which didn't appear previously in scenario 1

Now my Question is
1.Even though the CDT pv is single why am I getting multiple values in report for emp ID
2.when I gave an indexing to the CDT pv in report how come the values are getting populated.
I am in Version 7.4

@harshav Hi, here goes the explanation to your questions as per my knowledge:
1.Even though the CDT pv is single why am I getting multiple values in report for emp ID
When you choose the option 'Include data from sub-processes', the data starts appearing from the sub-processes in the report for the each parent process row in the report. So let's take your case as an example. Let's say you have a PV by name 'employeeDetails_cdt' in the parent as well as child processes. While creating a report, choosing the option 'Include data from sub-processes' populates the particular parent process record with the values found for pv!employeeDetails_cdt.empID from parent as well as child processes. So that's how you end up in seeing multiple values, as your configuration itself is trying to query the values from multiple (parent and child) processes. If you know that the values are going to be same across the processes irrespective of hierarchy, then you may go for applying a function such as fn!union() to refrain from seeing duplicates in the report. Further you observe this behavior only for parent processes, as they are the ones that will pull more than one value depending on the child processes it has got. You won't observe this pattern for a child/standalone process (or a process that has no sub-process node configured in it) as it just gets a value of its own context but not any other values. You may see some null values out of the multiple values being seen here, but I guess that might be because of the reason that the values aren't populated in the corresponding sub-process.

2. When I gave an indexing to the CDT pv in report how come the values are getting populated.
I would leave this to others but a wild guess is that this could be because of the casting, that is, employeeDetails_cdt[1].empID resolves to a data type which is of type single.

Re the Appian Version, to the best of my knowledge, at-least the functionality (Reporting and the configurations in it) which we are discussing here hasn't got any changes and so isn't dependent on the version.

Let's see if other practitioners could give some invaluable suggestions.

Hi sikhivahans, thanks for the inputs, Now I have to shoot one more question,
Shall I change the value of the Include subprocesses to SPs and make the value to No and move it to prod, or is it ok if I move that giving Indexing like Pv!empDetails[1].empID and call the MP in report context, which one would be suitable.
Reason for asking this is , if there is no value in empDetails, will my report give me indexing errors.?

@Harsha,Yes, As per my knowledge its better to add all the process models in the context (MP and SP) to avoid null values and indexing errors.

@harshav Sure, give me few minutes, I am working on this and will get back to you shortly.

Have you tried using union function to eliminate duplicate values coming out of several sub processes?
For example,
union(index(pv!employeeDetails_cdt,"empID",""),index(pv!employeeDetails_cdt,"empID",""))

hi amitl thanks for the reply , when I gave the value of employeedetails_cdt[1].empId that itself solved my problem , but when I was wondering is if I give like this if the value is not there at that time , will the indexing throws me an error? if so I would go with the adding of all the subprocesses.

Yes, there would be an index error. However, Appian will display blank value when it occurs and not the error description in the column. If you want to handle the error, you may try something like following by using index function.

index(index(pv!employeeDetails_cdt,"empID",""),1,"")

@harshav There isn't a problem with the usage of employeedetails_cdt[1].empId but I would personally recommended proceeding with usage of index() or property(). The beauty of the portal report is that, there wouldn't be any breakage if there is an error in the evaluation of the expression, except that you will see null values because of the failure in the evaluation of the rule. Also stay away from using union() if possible, as it might bring null values into picture which is not desired by you(and off-course it needs additional processing to remove null values) as per my understanding of the use-case here.

Just to let you know, there wouldn't be a problem as per my quick tests but you will find a null value when the PV isn't yet populated. So in this case, you can assign a default value such as -1 (using index() or property()) and skip those rows from processing by applying the filters appropriately.

Finally I would like to suggest to replicate the issue which you want to fix in production environment so that you can move ahead confidently.

Union function eliminates duplicate values and treats null value as a unique, underlying data is responsible for displaying null values and not the union function. Report will still display null values, if process variable from different sub processes has null value.