By default, generated process reports are stored in the EU_REPORT_FILE object. Any user with access to the Report Files screen can see all reports stored there. If you need to restrict report visibility by role — for example, limiting certain report types to specific teams — you can implement a data security pattern using two supporting objects, a virtual object, and an additional process.
How It Works
When a process generates a report, a record is created in EU_REPORT_FILE containing the file name, status, and download link. To apply role-based access, reports are categorised into named Collections. Each generated report is linked to a Collection, and data security rules on the Collection object determine which roles can see which reports. Users access reports through a secured virtual object screen rather than the standard Report Files screen.
Step 1 — Create the Supporting Objects
You need two supporting objects:
Report Collection — defines the categories of reports (for example: Monthly Reports, Finance Reports, Regional Reports). This object must have data security enabled and include a unique identifier attribute for the collection name. Data security rules are applied to this object.
Report Details — links each generated report to a Collection. This object requires a reference to EU_REPORT_FILE and a reference to the Report Collection object. Each time a process generates a report, a corresponding record must be created here. If a report has no Report Details record, it remains visible to all users through the standard Report Files screen.
Step 2 — Create a Virtual Object
Create a virtual object that joins EU_REPORT_FILE to Report Details, and Report Details to Report Collection. This is the screen through which users will access reports. It should include at least one attribute in the unique identifier and expose the report file details, the associated collection, and any additional attributes from Report Details.
Step 3 — Create a Report Details Process
Because process reports are generated after process outputs are written, you cannot reliably create the Report Details record from the same process that generates the report. Create a separate process whose sole purpose is to insert a record into the Report Details object. This process should accept parameters for at minimum the report name and the target collection.
From your main reporting process, trigger this process by writing a record to EU_RUN_PROCESS with the report name and collection as parameter values. If a report should appear in more than one collection, call the process once per collection.
Step 4 — Apply Data Security
Configure data security on the Report Collection object:
Create a data security role for each group of users who should have access to a specific collection (for example: Finance Team).
Apply the role to the Report Collection object.
Define a filter so the role can only access the permitted collection values.
Assign users to the appropriate data security roles.
Users assigned to a role will only see reports associated with the collections permitted by that role, accessed through the virtual object screen.
For guidance on configuring data security roles and rules, see Configuring Data Security Roles.