Record data, active processes, and process reports

Certified Senior Developer

I have a requirement to add a new field, contained in a record, to an existing process report. In an interface a gridField with filters is used for displaying the task data, but cannot find a way to get this data in a way that makes it available for both new and previously started active processes.

  • Process Report is tasks per process model
  • Process Report is tasks per process model
  • Process uses Records for data management ()
  • Requirement to get additional data from the Process into the Process Report
  • Additional data is a value found in the Record
  • Process reports cannot index Records
  • Less than ideal solution has been to add process variables for any data point needed from the record
  • These single data point process variables can then be seen in the process report
  • Process report is displayed in an interface using a a!gridField()
  • Data for the gridField is pulled using a!queryProcessAnalytics()
  • a!queryProcessAnalytics() uses logicalExpressions in an a!query() to filter data

  • Query filters fields found in the task report for filtering. e.g. "field: "c8"
  • Adding another process variable to add data as a new field in the process report will work for all processes started after it's addition
  • Previously started active processes do not have access to this new process variable
  • Editing the active process to add and set the process variable makes the new value available in the active process
  • Editing the active process to add and set the process variable does not update the process report with the newly added data

  • Is there a way to filter data using a field in Record contained in the process report?
  • Is there a way to add and set new process variables in active processes so they will show in the process report?

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Senior Developer

    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.

  • 0
    Certified Senior Developer
    in reply to srikanthreddy9369

    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

  • 0
    Certified Senior Developer
    in reply to zakarym5342

    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.

Reply
  • 0
    Certified Senior Developer
    in reply to zakarym5342

    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.

Children
No Data