How does contextProcessModels property of a!queryProcessAnalytics() function wor

Sikhivahans, thanks for the info. I should be able to work out a solution with that.

But what I don't understand is why can't I get the 1 context of a process to work. If I switch the report used to one I just created making a copy of "Active Processes" and add the pp!id to that report, and then use contextProcessIds passing in the ri!processId (which I also display and can see is correct), it still returns an empty set. See the screen shot. If the report context is now Process and I'm passing in a valid processId for that environment, than shouldn't it return that 1 process?

To find the context you can edit the portal report and see Report Context and use the same on queryProcessAnalytics

Greggl, for your last comment, context is different from column filtering. You need a filter not context for active process report. Try process report templates for using context on PMIs

I don't understand. Sikhivahans is saying it can't be a Report Context of Process Model as must be Report Context of Process. I built a report of active processes which should have a context of Process but does not work. And now you are saying I need a Filter not Context but a Filter on a Report with Context of a Process Model will not work as the Report Context would be a Process Model.

@greggl Now the category of the report, that is 'All Active Processes' chosen by you doesn't need a context at all(you may also see in the Process Report that there isn't a chosen context whereas in earlier report you have Process Model as context), that is you don't need any of the contextGroups/contextProcessIds/contextProcessModels/contextUsers context parameters. If at all the Process Report needs a context, it would have asked you at the beginning of the report creation itself for a Process Model or Process or User or Group(s) etc. Still in this case also, you need to add a Process Id in the report and use the corresponding field in the queryFilter later.

Please bear in mind that a!queryProcessAnalytics() demands you the context only on need basis. In case of 'All Processes', context isn't needed. And in case of reports that accepts User as a context also doesn't need a context. If you send a context, the report accepts it, else the context of the user evaluating the expression will be chosen.


Few categories which will serve your purpose of testing 'contextProcessIds' are as follows:
1. Current Tasks for Process
2. Sub-processes per Process
3. Tasks by process

Active processes portal report doesn't have a context, it basically returns you all the active processes regardless of the process model. So, you can only have filters to filter out rows.

For example, to show only specific process model instances add the process model id column to the report and then apply filter on the model.

@greggl Actually going through the documentation at https://forum.appian.com/suite/help/16.1/Process_Reports.html ('Report Descriptions' section in particular) will help you understand which type of Process Reports need a context and which doesn't.

And you can also identify from the category as well, for instance 'All Processes' Process Report is intended to report on all processes but not against a specific process and so it doesn't require a context. Also Appian won't ask you for a context for those Process Reports that execute independent of the context.

Sikhivahans,
All the examples you list below require selecting the process instances. I just want to show the open Tasks for the current Process on the Process-backed record. I want to display the Tasks for the current Process ID. Obviously I can't pre-select the process ids when building the report as they're determined at run time. I thought I could filter to the current process using the current process id, but if a report can't be built that would have Process at the context (like all processes for a given process model - but that would have a context of Process Model I believe); so perhaps using contextProcessIds is the wrong approach. How would you use queryProcessAnalystics with a report to return the Tasks for the current Process?

Few categories which will serve your purpose of testing 'contextProcessIds' are as follows:
1. Current Tasks for Process
2. Sub-processes per Process
3. Tasks by process

So here are a few ways of doing it:

1. Choose 'Tasks by process' category and build a Process Report as desired by you. As a context, choose a process instance initially while creating and saving the report (Please bear in mind that choosing a Process Instance as context is namesake and later on you will be overriding this in the a!queryProcessAnalystics() by making use of 'contextProcessIds' argument). And later on in the report, you need to pass the desired process id (identifier of the Process Backed Record) as 'contextProcessIds'.

And re your statement 'Obviously I can't pre-select the process ids when building the report as they're determined at run time' - Select a process instance of your wish at the design time. But override the context of the Process Report by populating the 'contextProcessIds' argument of a!queryProcessAnalystics() with the value of the Process Id that comes from the identifier (rp!id) of the corresponding Process Backed Record. Simply speaking, choosing a process at design time is just to save the report and the context will be overridden when you invoke the a!queryProcessAnalystics() with a desired value for 'contextProcessIds'.

2. Choose 'Tasks by process model' category and build a Process Report as desired by you. As a context, choose a process model initially while creating and saving the report. And later on in the report, you need to pass the desired the Process Model as 'contextProcessModels' and additionally pass the required process id (identifier of the Process Backed Record) as a queryFilter.

You may choose any approach depending on your convenience and there isn't any wrong in choosing one over the other and it completely depends on your requirement. I would generally prefer the second way as it will also have PVs available for reporting.

I assume that you don't have a issue in sending the process id as a context (as per approach - 1) or filter (as per approach - 2) as the process id will be available as the identifier of the corresponding Process Backed Record.

Got it, thanks! I really appreciate the excellent information and pros and cons of 2 solutions. Thanks again.
-Gregg