Ability to Configure the User Account Used for Scheduled Report Execution

What is the problem or goal the end user is trying to solve or accomplish?

Customers using row-level security (RLS) in Cube or similar authorization logic rely on Jinja macros like __user to enforce access control based on the current user identity. Scheduled reports in Preset are executed using a system service account, which lacks this identity context. As a result, reports return empty data, even though dashboards render correctly for logged-in users.

How are they solving it currently?

Some customers attempt workarounds such as relaxing Cube's securityContext logic when no user is present, or using fallback roles with elevated access. However, these approaches may compromise data security or require manual configuration changes.

What is the recommended solution by the Customer?

The customer would like the ability to:

• Know which user (or service account) is used to execute scheduled reports.

• Optionally configure or override the user account used for report execution, so that access roles can be respected in systems like Cube.