Skip to main content
sameeru0003
Known Participant
August 5, 2026
Question

Unable to Access Process Variable in User-Centric Task Report

  • August 5, 2026
  • 9 replies
  • 49 views

Hi Everyone,

We have two task reports in our application:

  1. User-Centric Report – Used by end users to view and take action on tasks assigned to groups they belong to.
  2. Process-Centric Report – Used by administrators who can access all tasks across the application.

Our task creation flow works as follows:

  • An external system calls an Appian API.
  • The API triggers a Process Model.
  • The process performs some processing and creates a review task.
  • Task data is displayed in both the User-Centric and Process-Centric reports.

We recently introduced a new property/field that is passed from the API to the Process Model. This value is also being stored in a database from within the process.

Our requirement is to display this new field in both reports.

Current Status:

  • In the Process-Centric Report, we are able to access and display the value using process variable mappings.
  • In the User-Centric Report, process variables are either disabled or not available as report columns.

What we have tried:

  • Creating an Expression Rule to fetch the value from the database.
  • Using the expression rule as a column source in the User-Centric report.

Unfortunately, this approach did not work.

Questions:

  1. Is there a supported way to expose a Process Model variable in a User-Centric task report?
  2. What is the recommended approach to display a custom property/field in both User-Centric and Process-Centric reports?
  3. Would storing the value in task-related data or another Appian object be a better design pattern for this use case?

Any suggestions or best practices would be greatly appreciated.

Thanks in advance!

9 replies

shubhama926776
Brainy
August 5, 2026
  1. PVs can appear in a task report if the report’s Report Context process model is set to expose that model’s variables.
  2. Do not say “same for both” because the configs differ, but also do not say task reports cannot show PVs. The key is the report context, not whether the report is user-centric.
  3. Best practice is to read the field from DB/record data so neither report depends on report-context or PV configuration.

    Save the API value to the DB/record field you already have. Build both reports from that record/DB source so neither depends on process-variable config. If you must stay in process analytics, then set the report’s context process model and add the PV as a column.

    https://docs.appian.com/suite/help/26.7/Process_and_Report_Data.html
शुभम्
mathieud0001
Brainy
August 5, 2026

I agree with this approach. Avoid PVs if you can.

harshas2775
Brainy
August 5, 2026

For each of the Process report types’ context differs and thus underlying report data attributes can differ basis the context. If the context of your User Centric task report is ‘Tasks assigned to group’, as per my understanding of your description, then no - you cannot have Process model variable added to this report because the context is a group and not a process. Many different process models can be the involved in this report and  variables may not be common among them. 

For 2nd question, since the data is available in the process, but your User-Centric report context is as per group, you cannot add the custom field/property to your report.

Best solution would be to ditch the process reports and build two interfaces with grid - one for users, another for admins. As you are already storing API data in database, using a record as source for the grid - this should be a quite easier to implement and manage as well. You can add security to record type so users see basis their respective group assignments and admins can see everything. 

sameeru0003
Known Participant
August 5, 2026

I have been using same way. We have interface which is being displayed to normal users and admins , two different interfaces. But the grid data is report data instead of recordtype, since the grid should display the appian info like assigments, taskitemstatus etc., How to achieve in this case.

harshas2775
Brainy
August 6, 2026

Store all the data you need from pvs to database. Create a record type and use that for your grid data. Now, task report has a lot of status like accepted, assigned etc you wont be able to store them all at each user action as task report does that easily so I suggest you to store and retrieve data from database and for such a column as task status which appian stores better do query process analytics to your task report and index the respective row to show in a column. Basically bring together best of both so you have flexibility and security to show data in grid using records as well as have the relative appian info shown as provided ootb. 

stefanhelzle0001
Brainy
August 5, 2026
sameeru0003
Known Participant
August 6, 2026

The link provides the inbuilt properties of task and process to be mapped to columns of report, which we have already implemented and used. However, a new column is introduced whose value is passed from API to process model and is also stored in DB. We had written an expression rule to call db and get new column value and had mapped that expression to column as well. The expression was not getting called in column of process report hence cannot fetch from db nor able to find pv! in user centric report.

stefanhelzle0001
Brainy
August 6, 2026

I know. This why I wrote this pattern. There is no other reliable way to get data into task reports from various processes.

sameeru0003
Known Participant
August 6, 2026

If we keep the design consideration aside, the only issue I am facing is when I export the grid data, exported file is not having value for the new column. We have report with new column but with empty values, but we are calling an expression to get db value in UI while binding the grid in interface. However when exporting we call report which has empty column and not able to explicitly bind the data.

a!exportProcessReportToExcel(
report: local!reportdata,
documentName: local!docName,
saveInFolder: cons!OPENTASKS,
onSuccess: { a!save(local!exportId, fv!newDocument) }
)