I have a process task report which I pass process context to and get tasks for this process. All is well up until the point where I want to create a new column in the task report. I want to add a text field to the report from a record type variable that is used in the process. I keep getting nulls from the query, however the columnConfig shows the correct name of the column, so changes were made to the report.
Discussion posts and replies are publicly visible
Creating Reports have a look into this we can't index a record type in reports.
https://community.appian.com/discussions/f/reports/34424/record-type-variable-inside-process-report
You are correct, thank you. It is however (yet again) poor design from Appian that this silently fails. I should be notified that I made a mistake by some kind of static analysis when saving the report.
Process (and task) reports are VERY OLD functionality within Appian, so sadly there are lots of things that "silently fail" in them. I believe they're working on making reports work with RecordType data, though. For the moment however if this is a bind for you, I believe the official guidance is to procedurally copy your RecordType data into a PV that can be reflected on the report as needed - not sure how feasible that is for you of course.
Keep in mind that you can still retrieve the fields from record types through a!queryProcessAnalytics, they just don't yet display in the actual process report object.
That is indeed true, however for this to work, I have to expose the whole record type, which is not only a performance issue, but also a security concern.
Why would it be a security concern? You can still reference any fields you need to in any grid / expression that would use a!queryProcessAnalytics.
Peter, while it's true that we can reference fields through a!queryProcessAnalytics in grids or expressions, the concern comes from the need to expose a larger set of data than might be necessary for the specific report or grid. When we pull in the entire record type to get access to a few fields, we might inadvertently expose sensitive or irrelevant data, especially in environments where data visibility should be tightly controlled. This could potentially lead to performance impacts due to processing large datasets and also raises questions about adhering to principles of least privilege and data minimization. It would be ideal if there were a more granular approach to select and expose only the necessary data fields from the record types, thereby mitigating both performance and security concerns.Principle of least privilege is a fundamental cybersecurity practice that restricts access rights for users to the bare minimum necessary to perform their duties. This principle extends beyond human users to applications, systems, and devices, ensuring that each entity has only the access it requires, nothing more. This approach effectively minimizes potential avenues for unauthorized access or lateral movement within systems
Yeah it's definitely on our radar to improve this, since it would be convenient to allow for more granular control. However, I disagree that this has any security impacts. There are always multiple levels between accessing your data:
All of these items are in full control of the low-code developer, so there would be no way to expose this information to users unless the developer made an explicit decision to show this information at the highest level (the interface level).
Really this is no different than a low-code developer that queries data from a database, stores all the columns in a local variable, and then shows only a subset of the data on a grid.
The concern about security isn't solely about the intentionality of data exposure but also encompasses the potential for oversight or error that could inadvertently lead to data being available when it shouldn't be. The principle of least privilege and data minimization isn't just a preventative measure against malicious actors but also a safeguard against accidental data exposure.
Implementing more granular control at the data access level can serve as an additional layer of security, acting as a fail-safe to ensure that only necessary data is accessible at each point of the process, regardless of the developer's intentions or potential oversights. This approach aligns with the concept of defense in depth, where multiple layers of security controls increase the robustness of the system's privacy and security posture.
Furthermore, while the analogy to querying a database and selectively showing data on a grid highlights the developer's role in data exposure control, it also underscores the importance of granular access controls at the data source level. Such controls not only reduce the risk of accidental overexposure but also streamline the development process by clearly defining what data is necessary and accessible for each application component, enhancing both security and development efficiency.
In essence, while the development process does provide significant control over data exposure, enhancing granularity in data access control can further bolster security and privacy, reducing the reliance on the developer's vigilance alone to prevent data exposure.