Record data, active processes, and process reports

Let's address your questions step by step:

1. Filter Data Using a Field in a Record in the Process Report:

   It seems you want to filter data in your process report using a field from a record. The a!queryProcessAnalytics() function is typically used to query process-related data, but it may not be directly able to access data in records. If you want to filter or include data from a record in your process report, you may need to consider alternative solutions. Here are a couple of options:

   • Custom Query: Instead of using a!queryProcessAnalytics(), you can create a custom query by directly querying the records containing the data you need. You can then build a report that combines data from both the process and the records in your interface.

   • Process Variable: If you must stick with a!queryProcessAnalytics(), you can use process variables to store the data you need from the record. When a task in the process starts or completes, update the process variable with data from the record. The process variable can then be included in the process report.

2. Adding and Setting New Process Variables in Active Processes:

   You mentioned that adding new process variables works for new processes but not for previously started active processes. This behavior is expected because process variables are typically set at the time of process initiation and are not retroactively applied to existing processes. There are a few ways to deal with this:

   • Reinitialize Active Processes: If possible, you may consider reinitializing existing processes to bring them in line with the updated process definition. This can be a manual effort and should be done with caution, as it may disrupt ongoing work.

   • Alternative Data Storage: If you need to access the new data for historical processes, you might consider alternative data storage, such as a dedicated database or external system, that can be queried for historical information.

   • Hybrid Approach: You could implement a hybrid approach where you continue using process variables for new processes and consider an alternative method (e.g., custom queries) for accessing historical data from the records.

In conclusion, addressing your requirements may require a combination of solutions, including custom queries and potentially changes to process initialization. It's essential to consider the trade-offs and the impact on existing processes when making such changes. The feasibility and best approach can vary depending on the specifics of your system and requirements.

Let's address your questions step by step:

1. Filter Data Using a Field in a Record in the Process Report:

   It seems you want to filter data in your process report using a field from a record. The a!queryProcessAnalytics() function is typically used to query process-related data, but it may not be directly able to access data in records. If you want to filter or include data from a record in your process report, you may need to consider alternative solutions. Here are a couple of options:

   • Custom Query: Instead of using a!queryProcessAnalytics(), you can create a custom query by directly querying the records containing the data you need. You can then build a report that combines data from both the process and the records in your interface.

   • Process Variable: If you must stick with a!queryProcessAnalytics(), you can use process variables to store the data you need from the record. When a task in the process starts or completes, update the process variable with data from the record. The process variable can then be included in the process report.

2. Adding and Setting New Process Variables in Active Processes:

   You mentioned that adding new process variables works for new processes but not for previously started active processes. This behavior is expected because process variables are typically set at the time of process initiation and are not retroactively applied to existing processes. There are a few ways to deal with this:

   • Reinitialize Active Processes: If possible, you may consider reinitializing existing processes to bring them in line with the updated process definition. This can be a manual effort and should be done with caution, as it may disrupt ongoing work.

   • Alternative Data Storage: If you need to access the new data for historical processes, you might consider alternative data storage, such as a dedicated database or external system, that can be queried for historical information.

   • Hybrid Approach: You could implement a hybrid approach where you continue using process variables for new processes and consider an alternative method (e.g., custom queries) for accessing historical data from the records.

In conclusion, addressing your requirements may require a combination of solutions, including custom queries and potentially changes to process initialization. It's essential to consider the trade-offs and the impact on existing processes when making such changes. The feasibility and best approach can vary depending on the specifics of your system and requirements.

Thank you for the thorough response!

One thing I didn't mention was that I'm using this report to pull back all the active tasks for the given process and that the value I'm trying to add to the report is meant to be used in a gridField to display, sort, and filter data.

I'm thinking the hybrid approach could be what I end up doing, but that seems like an option that will only work if I'm able to get the value in new process variable to show in the report.

I'v tried manually updating the active processes by editing, adding the new process variable, and then setting the value with a script task, but with this approach the new values don't show up in the report.  Is this approach what you mean when you say Reinitialize Active Processes?

Also, can you help me understand what you mean by a Custom Query?  Would this be something I do using a function similar to a!queryProcessAnalytics()?

Thanks in advance for your help

Hi Zakarym,

I'm glad you found the response helpful, and I'll address your additional questions:

Hybrid Approach and Updating Active Processes: You're correct that the hybrid approach involves using process variables for new processes and considering how to update the existing active processes. When you mentioned editing active processes and adding a new process variable with a script task, this could be seen as a form of updating active processes. However, it appears that this method isn't reflecting the new values in the report.

To clarify, when I mentioned "reinitialize active processes," I meant potentially recreating or restarting the active processes with the updated process definition, which might include the new process variable. It's a more comprehensive way of ensuring that the changes are applied to existing processes. This would involve some manual effort and would need to be carefully planned.

Custom Query: Custom querying refers to creating your own queries to retrieve the data you need from your records. It's not a built-in Appian function like a!queryProcessAnalytics() but can be done using Appian's data retrieval capabilities. You can create a custom expression or rule that queries your records and fetches the data you want to display in the process report. This data can then be combined with the process data in your gridField.

For example, you can use a!queryEntity(), a!queryRecordType(), or similar functions to query records. These queries can retrieve specific fields from records, which can be displayed, sorted, and filtered in your gridField.

The key difference is that custom queries are more flexible and can pull data from a variety of sources, including records, while a!queryProcessAnalytics() is specialized for process data. By combining these two approaches, you can create a report that displays both process data and relevant record data in your gridField.

To implement a custom query, you may need to work with an Appian developer who can help design and build the query logic based on your specific data model and requirements.

Keep in mind that the best approach depends on your specific needs and constraints, and it might involve a mix of the methods discussed above. Always thoroughly test any changes or updates to ensure they work as intended in your specific Appian environment.