Hello, if we are making changes to filters and context within dashboards and our users already have saved default filter views, will they run into issues once we push those updates to production? Would they end up with a status 400 error because certain filters or context no longer exist in the dashboard that the saved default filter view is trying to surface?

Great question. Based on the available knowledge sources, here's what you can expect: Impact on Saved Views When Changing Dashboard Filters Changing default filter values (e.g., "All Time" → "Last 30 Days"): • This will not overwrite or delete your users' existing Saved Views. • When a user applies their saved view, the filters will revert to whatever was stored in that view, regardless of your new dashboard defaults. [Saved Views] Adding new filters to a dashboard: • New filters will reset to All when an existing saved view is applied — the saved view doesn't know about the new filter, so it defaults it to "All." [Saved Views] Regarding the Status 400 Error Risk Yes, this is a real risk, but it's more specifically tied to removing or renaming LDM objects (attributes, labels, facts) that are referenced by dashboard filters or visualizations — not simply changing filter default values. From real-world cases in the community: • If a filter in a saved view or dashboard references a label/attribute that no longer exists in the LDM, you can get a

400

error like: "Some of given referenced 'labels' entities do not exist." [Slack thread] • Similarly, dashboards with filters referencing deleted attributes can get stuck loading indefinitely. The fix in those cases involved manually removing the broken filter references via the API. [Slack thread] Recommendations 1. If you're only changing filter default values (not removing/renaming LDM objects), users' saved views should continue to work — they'll just override the new defaults when applied. 2. If you're removing or renaming filters/attributes in the LDM, use the Impact Analysis tool in the LDM modeler to detect which analytical objects (dashboards, insights, metrics) will be affected before saving. [Monitor Model Changes] 3. Be aware that impact analysis only checks within the current workspace and does not cover child workspaces. [Monitor Model Changes] 4. Also note that using a declarative

PUT

API to replace a workspace definition previously deleted saved views, though this has since been fixed. [Slack thread] In summary: changing filter defaults alone is low-risk for saved views, but removing or restructuring filters/LDM objects that saved views reference can cause 400 errors. 👍 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.

@kapa.ai, in this specific instance we have removed certain filters and changed their names/behavior. Would that cause a status 400 error for individuals using previously saved default filter views?

Based on the knowledge sources, here's what the evidence suggests for your specific scenario: Removing Filters When you remove a filter from a dashboard, the GoodData docs note that "when you delete an attribute, its dashboard filter is automatically deleted." [Monitor Model Changes] Real-world cases confirm that dashboards with filters referencing attributes that no longer exist in the LDM can fail to load entirely — in one case, a dashboard was stuck loading indefinitely until the broken filter reference was manually removed via the API. [Slack thread] Renaming Filters/Attributes According to the LDM change documentation, renaming an object results in "names of the affected analytical objects are updated — no negative impact." [Monitor Model Changes] However, community cases show that in practice, renaming LDM fields has caused

400

errors with messages like "Some of given referenced 'labels' entities do not exist" — suggesting that in some scenarios, renaming can still break references in existing visualizations or filters. [Slack thread] Impact on Saved Views Specifically The knowledge sources do not explicitly describe what happens to a user's saved default filter view when a filter it references is removed or renamed. However, given that: • Saved views store specific filter states tied to filter identifiers, and • Broken filter references have caused

400

errors and loading failures in dashboards generally, it is reasonable to expect that a saved view referencing a removed or renamed filter could cause issues — but I cannot confirm with certainty that this manifests as a

400

error specifically for saved views, as the knowledge sources don't cover this exact scenario. My recommendation: Test this in a staging/dev environment before pushing to production, and be prepared to use the API to inspect and clean up any broken filter references in affected dashboards. 👍 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.

Hi Nick, we have reviewed the response from our AI Assistant and can confirm that you would likely run into issues with the 400 error because you’ve re moved filters or context which no longer exist in the dashboard and if you’re updating the filter contexts. And as mentioned above, we would always recommend any such changes to first verify in a test environment before pushing to production

Hi @Michael Ullock, thank you for the confirmation. We test our changes in a qa environment before pushing to prod but this appears to be a user specific issue. Essentially one of our users is getting the error but our other users are not and neither are we. Is there a way for us to reset saved dashboard views that our users may have created? We are making a lot of changes to our dashboards and we don't want to continue to run into this issue if the filter changes are what caused it.

Given you’re making frequent updates to dashboards and filter contexts, it’s a good practice to take backups so you have a clear rollback point if a change causes unexpected impact. Here’s the backup guidance: https://www.gooddata.com/docs/cloud/manage-organization/organization-api/backups/ I’d also recommend managing and tracking these changes via the declarative workspace layout, which helps keep workspace configuration consistent and makes it easier to review and deploy changes in a controlled way: https://www.gooddata.com/docs/cloud/create-workspaces/declarative-interface/#workspace-layout

@Michael Ullock just being clear here, fact that changing the base of a dashboard doesn't gracefully support saved views is pretty big deal. • Our customers are using gooddata on a daily basis and we're trying to refine and update them along the way • If you're saying using a saved view as a default for a dashboard could cause the dashboard to be non-functional ◦ Then it puts us in a bad position because customers are not able to fix it themselves ◦ There's no out Rolling back is possible, but there's likely very little ways for us to confirm the issue outside of our production environment

Hi Steve, in general, saved views are user-specific, so it is possible for one user to hit an issue while others (including admins) do not, depending on what that user previously saved as their default view. In some cases, if a saved view (or the dashboard itself) references a label/attribute that no longer exists (for example after filter/context changes), it can result in a 400 error such as: “Some of given referenced ‘labels’ entities do not exist.” That said, we don’t yet have enough detail to confirm whether what you’re seeing is expected behavior or not in this in this specific case. If you can share a full overview of the use case, we can validate the behavior and advise on the best path forward. If you provide a complete overview and a walkthrough of what you’re updating and how, we can verify this for you on our side. Also, we didn’t receive a Trace ID from the the previously mentioned failing user. If you reproduce the issue and provide the Trace ID from the error we can review the backend logs and confirm exactly what object reference is failing. Once we have the Trace ID and the full context, we’ll be happy to dig in and help identify the best solution.

If this scenario occurs: • I create a default view with filters • The dashbaord filters are modified • The default view no longer functions • User is no longer able to use the dashboard because it errors on them • I cannot clear the default view because it is broken before I get the ability to clear the view

Hi Steve, I don't believe that is the case. I have tested the scenario where I've deleted a Dashboard filter which is used in other user's saved view. The filter simply disappears from his view but Dashboard still normally functions. Are you seeing any different behavior?

@Michael Ullock and @Julius Kos we submitted a support ticket: https://support.gooddata.com/hc/en-us/requests/132247 Containing some of the issues we're seeing. It looks like we've got a few customers with issues related to this. We tried to diagnose the best we can, but seems like there is an issue related to this conversation. let us know if this is or not related. Thank you. @Nick Dysle @Zachary Vanlancker fyi.

Hi Steve, I can confirm that we are working on the support ticket. We will get back to you with our findings as soon as possible.

Thank you

Hi Steve, our team are looking into your issue and will followup with you directly within this ticket you created here: https://gooddata.zendesk.com/agent/tickets/132247

Ok, just making sure we're looking into the details of the errors we're presenting. Thank you,