In a "semantic model", an Account dimension joins to a Transaction fact table that records both deposits and withdrawals. A bridge table relates Account to a Customer dimension because accounts are jointly held. Selecting a customer must filter the transactions, but selecting a transaction must not push filters back onto the customer list. How should the cross-filter direction on the bridge relationships be configured?
- ASet bidirectional filtering on every bridge relationship so filters travel freely in both directions between Customer, the bridge, and Account.
- BDisable the bridge relationships and rely on a measure using CROSSFILTER to force two-way flow only when a transaction visual is rendered.
- CKeep single-direction filtering from Customer through the bridge towards Account so customer selections flow to transactions but not back to the customer list. Correct
- DMake the Customer side of the bridge filter in both directions while leaving the Account side single-direction towards the transactions.
Why A is wrong: Bidirectional filtering would let transaction selections flow back to the customer list, which is the very reverse propagation the requirement forbids.
Why B is wrong: Disabling the relationships removes the join entirely, and forcing two-way flow contradicts the requirement to keep the customer list unfiltered by transactions.
Why C is correct: Single-direction filtering propagates the customer filter forward to transactions while preventing reverse flow, which exactly matches the stated one-way requirement.
Why D is wrong: Two-way flow on the Customer side still allows reverse propagation into the customer list, so this mixed setting violates the one-way condition the scenario demands.