Hello everyone, I'm facing an issue with cascading filters in GoodData and I'd like to know if anyone has experienced something similar or if there is a recommended solution. I have a dashboard with multiple attribute filters. When configuring the Parent Filters for one of them, GoodData automatically infers the dataset used to establish the dependency. The problem is that the inferred dataset is not the correct one according to our logical data model. For example, GoodData automatically creates the following dependency:

Company → linked using

ArticuloID

However, in our model, Company and Article are not directly related. The correct relationship should be established through the transactional dataset (

FacV_ID

), which is the common context shared by both attributes. The expected configuration would be:

Company → linked using

FacV_ID

The issue is that, because GoodData detects only one inferred path, the dataset selector is disabled and there is no way to override the automatic inference. In other cases, when multiple paths are available, GoodData correctly enables the dropdown and allows selecting the desired dataset, but that option is not available here. As a result, the cascading filter behaves incorrectly because it filters values using

ArticuloID

instead of the transaction (

FacV_ID

). My questions are: 1. Is there any way to override the automatically inferred dataset when the selector is disabled? 2. Is this a known limitation of the platform or could it be considered a bug in the inference algorithm? 3. Is there any recommended modeling approach to force GoodData to infer the correct dataset? Any advice or suggestions would be greatly appreciated. Thank you!

Hi Tomas, Thanks for sending this in. To answer your questions, when GoodData detects only one path connecting the parent and child attributes in your Logical Data Model (LDM), the dataset selector remains disabled, and you cannot manually force an alternative selection. The selector is only enabled when multiple valid connection paths are detected between the two attributes in the LDM, kindly refer to our documentation on Set Up Cascading Filters. This is a known platform limitation and expected behavior of the analytical engine. GoodData's engine resolves paths between datasets automatically based on existing LDM relationships, foreign keys, and connection points. If it is only detecting the path through ArticuloID, it means that from the engine's perspective, this is the only valid physical join path defined in the LDM that connects the datasets containing Company and the child attribute. To route the cascade through your transactional dataset (FacV_ID), you must adjust your LDM. The recommended approaches include ensuring that the foreign keys (FK) connecting your attributes (Company and the child attribute) are properly pointing to the transaction dataset (FacV_ID). If the connection from Company to FacV_ID is missing or the arrow direction in your LDM does not allow the cascade to flow downward to the transaction table, GoodData will ignore that path . If GoodData is choosing an unexpected path (e.g., through ArticuloID), you may need to restructure your LDM to eliminate this alternate relationship path. This ensures that the only available path for the engine to resolve is the desired one through FacV_ID. If the grain mismatch is causing incorrect paths, you can try creating a dedicated database view at the transaction grain (FacV_ID) that explicitly contains the relationship fields you need, and register it as a new dataset in GoodData to establish a clean, unambiguous path. If this doesn’t help kindly share a direct link to the insight/ dashboard, so that we can check this further.

Yvonne, thank you for your reply. To be honest, I don't quite follow the reasoning that the platform assumes there is only one way to apply cascading filters when the company dataset is linked to transactions from various modules (accounting, purchasing, sales, etc.)—much like the item dataset is linked to purchasing, sales, stock, and production transactions. In my LDM, the various transactions use both the company master and the item master as foreign keys; therefore, I do not understand what modification I could make to my LDM to resolve this issue.

Hi Tomas, Could you share a direct link to this report so that we can have a closer look?

Hi Tomas, Thanks for the detail and the screenshot — that comparison is really helpful. To pin down exactly why the engine is resolving the path through ArticuloID instead of FacV_ID, we need to see the actual LDM: the arrow directions, grain, and any intermediate datasets between Company, Article, and your transactional tables. That's the only way to spot what's giving the engine a shorter path than the one you're expecting — it's not something we can diagnose from a description alone. Could you share a direct link to the dashboard/insight where this filter lives, and make sure that our support user has access to the workspace as an admin? With that, we can trace the exact path and give you a concrete fix rather than general guidance. Thanks for bearing with us on this!

Hi Joseph, i can send u the ldm in a private message or i can send u the project id and u can look he model in the platform

Hi Tomas, Please feel free to share a direct link to the project via dm. Thanks.

I already send the link to Yvonne

Hello Tomas, Thanks for sharing the link to the dashboard. We will review this and get back to you as soon as possible.

Hi Yvonne,

Hey Tomas, Sorry for the delay in getting back here. I was trying to dig into this further and actually overlooked the main difference here. The "Empresa" filter is currently built on the attribute titled "Empresa" (display label "Descripcion"). In the LDM, that specific attribute only has one valid connecting path to the rest of your model, which is why the dataset selector doesn't appear — the engine only shows the selector when multiple valid paths exist. It's the same underlying reason Grupo didn't show a selector either, just a different attribute this time. The dataset does have a separate attribute, "EmpresaID," which is properly connected to your transactional tables (including FacV_ID) and would allow selecting the dataset. Let us know if you'd like guidance on how to point the filter at that attribute instead. On a side note, I understand this is a TOTVS workspace. You should reach out directly to TOTVS support in regards to their custom solution. TOTVS is our exclusive partner in Latin America and is responsible for helping all its customers in this region. Should TOTVS face any issues they cannot resolve, they will contact GoodData support directly.

Good morning, Joseph, I tried the option you mentioned using EmpresaID, but it still doesn't let me use the relationship selector. Regarding seeking help from TOTVS: I work for a TOTVS partner in Argentina that is responsible for the BI implementation.

Hi Tomas, We found the actual cause, and it's more fundamental than which Empresa attribute is used. Articulos has its own internal connections to four small accounting classification tables (Centro de Costos, Item Contable, Clase Valor, Cuenta Contable), and each of those connects directly to Empresa. That creates a short internal path from Articulos to Empresa that has nothing to do with your sales/transactional data. When you add Empresa as a parent of the GRUPO filter, the system automatically resolves through that short internal path instead of through FacV_ID or any of your transactional tables — which is why it locks to a fixed link instead of offering a choice, no matter which Empresa attribute (Empresa or EmpresaID) is used. By contrast, Pais and Cliente don't have that kind of internal shortcut to GRUPO, so they only connect through your transactional tables — multiple genuine options exist, so the dropdown appears for those. This is a structural characteristic of your data model interacting with a known limitation in how the legacy dashboard platform resolves these connections, not a configuration issue on your end. Unfortunately there isn't a workaround available on our side for this particular case. We're sorry this wasn't the outcome you were hoping for, and appreciate your patience while we tracked this down. In regards to TOTVS, we have a contract in place with them including a list of designated support contacts who can reach out directly to GoodData Support by opening tickets directly. You should reach out to the people at TOTVS to include you in that list.