Forum Discussion
InvalidUnconstrainedJoin — sibling tables sharing same hub
Hi all,
Thank you @Azadsingh and @Kiran-7312 for confirming this is a modeling limitation rather than a relationship configuration issue.
After further discussion internally, we've settled on a solution: since end users don't functionally need KPIs or a proper star schema (fact/dimension). we will not build (or allow) any report/visual that pulls data simultaneously from the three tables that have a 1:m relationship with the Projet hub table.
In practice this means:
- Visuals can combine Projet with one of the "many" child tables (Commande FTTO, Gouv, or Task) at a time, which works fine since there's a single, unambiguous filter path.
- The 1:1 tables (Commande BTE, Modules SFP) can still be freely combined with each other and with the hub, as already confirmed.
- We're not attempting a model-level fix (bridge table, flattening, etc.) since it's not required by the actual reporting needs — we're just constraining what combinations are exposed to end users, either through separate pages/visuals per child table or by governing which fields can be used together.
This avoids the InvalidUnconstrainedJoin error and the cartesian product issue entirely, without requiring end users to add measures.
Thanks again for the insight — it helped confirm that this is fundamentally a data granularity/modeling issue, not something fixable purely through relationship settings.
I don't think there's a model setting that will completely solve this.
The invalid join error is usually a symptom of the data model rather than the relationship direction. Even if you change relationships to Both, Power BI still can't determine how to pair rows between two sibling fact tables because there isn't a direct relationship between them—only a shared parent (project) That's why the error persists.
The reason your 1:1 tables work is that Power BI can uniquely identify a single related row on each side. With two child tables that each contain multiple rows per project, there isn't enough information to know which rows should be matched together.
Adding a measure only forces the engine to evaluate the visual, but it doesn't create a valid row-level relationship. If both child tables contain multiple rows for the same project, you'll naturally end up with a many-to-many expansion (cartesian product), which is exactly what you're seeing.
If your users need to freely combine columns from different child tables without worrying about measures or relationship behavior, I'd look at redesigning the semantic model rather than the relationships. Depending on the business logic, that could mean:
Flattening the required attributes into a single reporting table.
Creating a dedicated bridge table if there is a real business key that links the child tables.
Restructuring into a proper star schema where visuals are built from dimensions and measures instead of combining multiple fact-like tables.
Unfortunately, if there is no business key that defines how commando FTO rows relate to gouv rows within the same project, there isn't a model-level feature that can infer that relationship automatically. Power BI is preventing an ambiguous join rather than failing to find one.
So I'd say this is fundamentally a modeling challenge rather than a relationship configuration issue.