155747 - no subject - I have created a process portal report i

@zulfiqarp The disadvantage of the PVs is that we can't observe the changes in the variables until and unless task submission takes place. I would like to suggest to strictly opt out of PVs as much as possible(atleast when we are making use of the dynamic metrics of task such as status, assignees etc). Also it requires addition of PVs as and when a new task is added, and deletion when a task is removed. Simply speaking it might not be a good idea to hold data in PVs which is already available to us in the form of Task metrics.

If I understand the question correctly, I would like to suggest to make a join on Process and its Tasks. You could identify all the tasks originating from the Process with the help of functionalities available in Appian as of now. The pseudo-code can be as follows:
Step - 1: Get the synchronous or asynchronous subprocess ids of the desired main process using the Shared Component 'Get Sub Process Details' available at https://forum.appian.com/suite/tempo/records/type/components/item/i8BCLGOdlMUpdGVqT-RV7oRg74uEGJO5yYYx2sxnURrc2O8fUDHwGC-JagCuOdubQ/view/summary and an array of process ids could be the resultant data. You can ignore this step if you don't want to get the task information from the subprocesses and the current process id is the only resultant data.
Step - 2: Using the process id(s) obtained in Step - 1, you can obtain the Tasks with the obtained process ids as filters(i.e. Tasks originated from the corresponding process ids) by querying the 'Current Tasks for Process' report with the help of a!queryProcessAnalytics() or getportalreportdatasubset(). (Note: a!queryProcessAnalytics() is highly recommended over getportalreportdatasubset())

The information obtained in Step - 2 is the resultant task information of the desired process(es) and this will always helps you to fetch dynamic data (in case of Active tasks) because we are only depending on the task metrics, and changes in the task metrics can be reflected as and when the SAIL interface is reloaded.

Coming to the implementation in SAIL, as the relationship between the process and task is not always one - one, you could provide a link to the process, and upon clicking a process, you could perform Step - 1 and Step - 2 and show the resultant data in a separate section.

I agree that this kind of approach consumes time to build, but to the best of my knowledge, it results you in a reusable and robust approach and will further doesn't create any work when a new user input task is added or removed in a process at any level.

@zulfiqarp The disadvantage of the PVs is that we can't observe the changes in the variables until and unless task submission takes place. I would like to suggest to strictly opt out of PVs as much as possible(atleast when we are making use of the dynamic metrics of task such as status, assignees etc). Also it requires addition of PVs as and when a new task is added, and deletion when a task is removed. Simply speaking it might not be a good idea to hold data in PVs which is already available to us in the form of Task metrics.

If I understand the question correctly, I would like to suggest to make a join on Process and its Tasks. You could identify all the tasks originating from the Process with the help of functionalities available in Appian as of now. The pseudo-code can be as follows:
Step - 1: Get the synchronous or asynchronous subprocess ids of the desired main process using the Shared Component 'Get Sub Process Details' available at https://forum.appian.com/suite/tempo/records/type/components/item/i8BCLGOdlMUpdGVqT-RV7oRg74uEGJO5yYYx2sxnURrc2O8fUDHwGC-JagCuOdubQ/view/summary and an array of process ids could be the resultant data. You can ignore this step if you don't want to get the task information from the subprocesses and the current process id is the only resultant data.
Step - 2: Using the process id(s) obtained in Step - 1, you can obtain the Tasks with the obtained process ids as filters(i.e. Tasks originated from the corresponding process ids) by querying the 'Current Tasks for Process' report with the help of a!queryProcessAnalytics() or getportalreportdatasubset(). (Note: a!queryProcessAnalytics() is highly recommended over getportalreportdatasubset())

The information obtained in Step - 2 is the resultant task information of the desired process(es) and this will always helps you to fetch dynamic data (in case of Active tasks) because we are only depending on the task metrics, and changes in the task metrics can be reflected as and when the SAIL interface is reloaded.

Coming to the implementation in SAIL, as the relationship between the process and task is not always one - one, you could provide a link to the process, and upon clicking a process, you could perform Step - 1 and Step - 2 and show the resultant data in a separate section.

I agree that this kind of approach consumes time to build, but to the best of my knowledge, it results you in a reusable and robust approach and will further doesn't create any work when a new user input task is added or removed in a process at any level.