Hello, have their been any updates made to the back functionality after using a DrillToDashboard? We noticed back button in our UI and wanted to ask if that is new? Also, have there been any changes made to the insight export menu and/or functionality? @Steve Fox

Regarding your two questions: "Go Back" Button After DrillToDashboard The knowledge sources do not contain enough information to confirm whether the "Go Back" button visible in your screenshot is a new or recently updated feature related to DrillToDashboard navigation. While GoodData has made various drilling-related updates (such as drill down interactions, drill-into URL, and flexible filter control in drill configuration) [Flexible Filter Control], none of the available knowledge sources specifically document changes to a "Go Back" button in the DrillToDashboard flow. I'd recommend checking the GoodData Cloud release notes directly or reaching out to GoodData support for confirmation on this specific behavior. Changes to the Insight Export Menu/Functionality Yes, there have been several notable updates to export functionality over time: • Dashboard Slide Deck Exports: You can now export entire dashboards or individual widgets as PDF or PPTX slide decks. [Dashboard Slide Deck Exports] • Export Raw Data: A raw data export option (out of beta) allows downloading the data used to compute a report. [Export Raw Data] • New Scheduled Export Formats: Scheduled exports now support PDF, PPT, XLS, raw tabular data, and PNG for individual visualizations. [Scheduled Exports] • Show as Table / Export Behavior: When a widget is switched to "table view" and then exported to PDF or PPTX, the export will still show the original visualization, not the table view. If you want to export data in tabular form, you should export the dashboard to XLSX or export individual visualizations as tabular data. Regarding the specific insight menu submenu (e.g.,

IInsightMenuSubMenuComponentProps

), there is an alpha-stage

enableTitleConfig

property available in the SDK, but this is marked as experimental. [SDK API Docs] 👍 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, Have their been any updates surrounding automatically surfacing alerts in the UI dropdowns?

Yes! The Alerts option appearing in the widget's ellipsis (…) menu is indeed a feature that was introduced in GoodData Cloud. Here's what the knowledge sources confirm: Alerts in the Widget Menu The Alerts option surfacing directly in the widget dropdown menu was introduced as part of the broader Alerts and Scheduled Exports feature released on October 3, 2024. This allows users to set up alerts on dashboard widgets to monitor metrics and get notified when specific conditions are met. [Alerts and Scheduled Exports] Since then, several enhancements have been made to alerts: • November 7, 2024 – Added support for alerts on individual attribute values, enabling multiple alerts for a single metric based on different attribute values. [Individual Attribute Alerts] • January 16, 2025 – A new in-app notification panel was introduced, so alerts can now be delivered directly within the GoodData web UI (in addition to email/webhook). [Notification Panel] • February 12, 2025 – Customizable alert names were added, making it easier to identify which alert was triggered. [Customizable Alert Names] • April 2025 – Dashboard creators can now customize the alert evaluation frequency per dashboard, overriding the organization-level default. [Alert Evaluation Frequency] So the Alerts submenu you're seeing in your screenshot is part of this evolving feature set, not something that was always there. It has been progressively enhanced since its initial release. 👍 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 I don't understand. That did NOT show up in our embedded UI until recently. Are you saying it has been there for over a year? I do not buy that.

You raise a fair point, and I want to be transparent about what the knowledge sources actually confirm. The Alerts feature was released for GoodData Cloud on October 3, 2024 as a general availability feature. [Alerts and Scheduled Exports] However, the knowledge sources also confirm that Alerts work with SDK version 10.12.0 or newer, and that using an older SDK version may cause problems with embedding. [Create Alerts] So it's entirely plausible that the Alerts option did not appear in your embedded UI until recently — this could be explained by: • Your embedded app recently upgrading to an SDK version that supports alerts (10.12.0+) • Your organization's admin recently configuring the required destinations/permissions needed for alerts to appear • The

CREATE_AUTOMATION

permission being granted to your users (users without this permission do not see the Alerts option in the menu) One community member also confirmed that alerts do work in iframes once properly set up. [Community Slack] So to directly answer your question: the feature has existed since October 2024, but it may have only recently become visible in your embedded environment due to one of the factors above. I apologize if my earlier response was unclear on this distinction. 👍 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 how do we remove it from the UI until we are ready for allowing customers to use it?

Based on the knowledge sources, there are a few supported ways to remove or hide the Alerts option from your embedded dashboard UI: Option 1: Control via isReadOnly (React SDK) If you embed the dashboard using the GoodData.UI React

Dashboard

component, you can set

isReadOnly={true}

in the

config

prop. This disables all user interactions that alter backend state, including creating/changing alerts. [Dashboard Config]

<Dashboard
  dashboard={dashboardRef}
  config={{ isReadOnly: true }}
/>

Option 2: Hide via menuButtonItemsVisibility (React SDK) The

IMenuButtonItemsVisibility

interface includes an

alertingButton

property. Setting it to

false

will hide the Alerting button from the dashboard menu. [Menu Button Visibility] Option 3: Disable per Visualization (Analytical Designer) You can disable the ability to create alerts for a specific visualization by editing it in the Analytical Designer and toggling off the Alert option under the Interactions tab. [Disabling Alerts] Option 4: Permissions-Based Control Users without the

CREATE_AUTOMATIONS

permission will not see the Alerts option in the widget menu. So restricting that permission from your end users is another way to suppress it until you're ready. [Community Slack] The most straightforward approach for embedded use cases is likely Option 2 (hiding the alerting button via

menuButtonItemsVisibility

) or Option 4 (permissions control). 👍 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, no changes have been made on our end to settings in GoodData but we are seeing alerts in PROD now but not in QA. Both environments have destinations set up. What could be causing this if you haven't made any updates?

New message text here

Hey @kapa.ai, I've checked that user permissions are the same and so is the SDK version. However, in DEV and QA,

GET /features

works and the FeatureHub payload includes

enableAlertingRollout: false

. In the embed, we don’t see the alerting UI there, which lines up with “flags actually applied.” In PROD,

GET /features

doesn’t complete, the browser blocks it (CORS: Datadog/RUM headers aren’t allowed on the preflight for

/features

). So FeatureHub never loads. Despite that, we do see alerting UI in prod. (1) What’s the intended SDK behavior when FeatureHub fails vs when it loads with

enableAlertingRollout: false

?

This is a very specific and technical question. Based on the knowledge sources available, I can only partially address it: What the Knowledge Sources Confirm The changelog for SDK version 11.3.0 includes this relevant entry: > "Return default feature flags on FeatureHub request failure." [SDK Changelog] This directly explains the behavior you're observing: • In DEV/QA: FeatureHub loads successfully →

enableAlertingRollout: false

is applied → alerting UI is hidden. ✅ • In PROD: FeatureHub request fails (CORS block) → SDK falls back to default feature flags → the default value for

enableAlertingRollout

appears to be

true

(or at least permissive enough to show alerting UI) → alerting UI appears. ✅ So the intended SDK behavior when FeatureHub fails is to fall back to default feature flags, rather than failing silently or suppressing all features. This is why you see alerting in PROD despite no explicit configuration — the defaults are being used. What the Knowledge Sources Don't Confirm The knowledge sources do not specify what the exact default values are for

enableAlertingRollout

or

enableAlerting

when the fallback occurs. I cannot confirm this with certainty from the available documentation. Recommended Action The root cause appears to be the CORS issue blocking the

/features

request in PROD (Datadog/RUM headers on the preflight). Resolving that CORS configuration so FeatureHub can load in PROD would likely bring PROD behavior in line with DEV/QA. This would be worth raising with GoodData Support if you need help configuring it. 👍 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, it looks like the failure is on the OPTIONS response for

<https://analytics.golmn.com/features>

. The browser compares the client’s

Access-Control-Request-Headers

to the server’s

Access-Control-Allow-Headers

. In your prod capture, the browser asked to send:

traceparent

,

tracestate

,

x-datadog-origin

,

x-datadog-parent-id

,

x-datadog-sampling-priority

,

x-datadog-trace-id

,

x-featurehub

but

/features

only allowed a smaller set (it included

x-featurehub

but not the Datadog/trace headers), so the preflight fails. What needs to change On

<http://analytics.golmn.com|analytics.golmn.com>

for

/features

(same path you already OPTIONS), set

Access-Control-Allow-Headers

so it includes every header your app may send on that request. Practically, that means at least adding the missing ones above. Would this be a change that needs to be made on your end?

Based on the knowledge sources available, I can offer some relevant context here. The CORS configuration for your GoodData organization — including which headers are allowed — is managed on the GoodData side via your organization's CORS settings. The documentation confirms that allowed origins (and by extension, CORS behavior) are configured through: • The Developer Settings UI on your GoodData instance (

https://analytics.golmn.com/settings

) • Or via the

/api/v1/entities/admin/organizations/<organization_id>

API endpoint [Enable CORS for an Organization] However, the knowledge sources do not explicitly document the ability to configure

Access-Control-Allow-Headers

(i.e., which request headers are permitted in preflight responses) through the GoodData CORS settings UI or API. The documented CORS configuration covers allowed origins, not allowed headers. What This Means Practically The specific issue — that Datadog/RUM trace headers (

traceparent

,

x-datadog-trace-id

, etc.) are not included in the

Access-Control-Allow-Headers

response from

/features

— is likely something that would need to be addressed by GoodData's engineering team, as it relates to how the GoodData backend responds to preflight requests on that endpoint, not something you can configure yourself through the standard CORS settings. Recommended Action I'd strongly recommend raising this directly with GoodData Support, providing: • The specific OPTIONS request/response headers from your PROD browser capture • The list of headers being blocked (

traceparent

,

tracestate

,

x-datadog-*

) • The endpoint affected (

/features

) This is beyond what can be self-configured based on the available documentation, and GoodData Support would be best positioned to confirm whether this is a backend change they need to make. 👍 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, I just wanted to let you know that we received your support ticket and we will follow-up with you directly there once we have reviewed this behaviour and have some clarification for you