@Julius Kos @Giorgos Malandrakis Hi, We just understood that a recipient of a scheduled export can access the scheduled export details clicking the ellipsis button and selecting Schedule export. Is this according to design? If above is according to design it seems like the recipient have no edit permissions, i.e. it can't edit the scheduled export. It is for read-only/info purposes? The issue for us, is that the recipient can click the recipient field and then they get to see the full list of recipients. This is a problem for us, because of data integrity/breach issue for us. Can you please give feedback on this, since this is a data breah issue it is important for us to be bale to address it quickly. I am referencing a previous converstaion below https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1761226596379639?thread_ts=1761057636.325169&cid=C04S1MSLEAW

Scheduled Export Recipient Visibility — Known Issue Thank you for raising this. Based on the available knowledge sources, here is what is confirmed: Is it by design? Yes, the current behavior — where the recipient list shows all workspace members — is by design, though it has been flagged as a concern by multiple customers. As confirmed by GoodData support: > "It is simply listing all workspace members there." [Community Slack] There is currently no built-in way to restrict the recipient dropdown to only show users within a specific group or subset of workspace members. [Community Slack] Read-only for recipients? The knowledge sources confirm that only the automation's creator or an administrator can edit, pause, or delete a scheduled export. Recipients viewing the schedule dialog would have read-only access. [Automation Permissions] Workarounds currently available Two partial mitigations have been discussed in the community: 1. Disable scheduling permissions for affected user groups — You can remove the

Workspace.CREATE_AUTOMATION

permission from specific user groups, which prevents those users from creating (and presumably accessing) scheduled exports entirely. [Community Slack] 2. Central management — You can manage and disable specific schedules per workspace via the Automation central management section. [Community Slack] Recommended next steps This issue — including the specific concern about recipients seeing the full recipient list — has been submitted as product feedback to GoodData's engineering team. [Community Slack] Given the severity you describe, I strongly recommend: • Contacting your GoodData Account Owner directly to escalate this as a high-priority issue. • In the interim, consider removing

CREATE_AUTOMATION

permissions from user groups where recipient visibility is a concern, as this is the most immediate available control. I'm sorry I cannot provide a more definitive resolution — the knowledge sources do not indicate that a fix has been released yet for restricting recipient list visibility. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.

@Julius Kos @Tom Kratochvil Based on the "Users with this permission can create automations, while other users will continue to receive alerts and exports from active automations they are subscribed to. However, only the automation’s creator or an administrator can edit, pause, or delete the automation." https://www.gooddata.ai/docs/cloud/create-dashboards/automation/#permissions The recipients/subscribers have NO edit, pause, or delete the automation. Can it be changed so that the scheduled export details are only read-only for the recipients/subscribers?

Hi Philip, This depends on the role of the users who are recipients/subscribers. We can certainly submit this as product feedback on your behalf. Our product team can review your request and maybe there is some way we can create some custom user role to fit your use case.

Hi @Joseph Heun, The main thing we need constrained is that the recipients that have read-only should not be able to click the Recipients and get the list of all users. Apart from that it is actually fine if everything else remain the same.

Hi Philip. This was reported to our team as product feedback.

@Shamil Akhmadyshev thanks