Often when designing a semantic model schema that uses bidirectional cross-filtering, the resulting model is ambiguous. Often, the accepted solution to this issue is to disable bidirectional filtering and make do with single direction cross-filtering. This is unfortunate, because bidirectional filtering is a powerful feature that can aid insights in reports. Another solution is to duplicate a certain dimension table (create a role playing dimension). This is also often undesireable, because two dimension tables have to be managed and often filtered in tandem.   It's not the case that bidirectional filtering always results in ambiguity, and it's not even the case that relationships currently dissallowed in semantic models due to ambiguity have to be ambiguous. Considering the path used in the relationship could, in many cases, resolve the ambiguity. Consider this model: Here it would be convenient and useful to be able to filter accounts based on selected invoices, and to filter accounts based on selected budgets. This would allow, for example, more direct comparison of budgets and invoices associated with a given account. Unfortunately this is not possible: setting the accounts -> budgets and accounts -> invoices relationships to cross-filter in both directions gives an error: Actually, even setting one relationship to cross-filter in both directions results in ambiguity. This is undesireable and is the reason that bidirectional cross filtering is discouraged.   It's easy to see why this happens : the Date dimension can filter accounts either through invoices or through budgets. The unfortunate part is that this effect is unrelated to the intention to filter the two fact tables from the accounts dimension; the Date dimension is not directly related to the accounts dimension.   It would be good if we had a feature in PBI to limit the filtering effect of a relationship to a certain group of tables (similar to the effect of a VLAN in a networking setup). For the above example, we could: Assign the Date -> invoices and Date -> budgets relationships to group A Assign the accounts -> invoices and accounts -> budgets relationships to group B Disallow filtering operations from a group A relationship to propagate along a group B, and vice versa This would allow/maintain the advantages of bi-directional filtering, while removing the perils of ambiguous relationships. Situations where all four tables are used in the same visual would still parse, because there is at most one relationship actively defined between each pair of tables.   I realise that this would not be a light feature to implement, but I think it has the potential to add a lot of value in terms of the insights available from models and the clarity of semantic models themselves. ... View more