Why Is My Relationship Inactive in Power BI

Desktop?
Summary
The Power BI Desktop tool now attempts to utilize bi-directional relationships when it
can. If any ambiguity exists, some of your relationships may become inactive. If you are
seeing inactive relationships (the dotted line), take a look in Advanced properties to see
if the “cross filter direction” is set to “Both” rather than “Single” for some of the
relationships. This is particularly true if you have multiple fact tables in your dataset –
it’s recommended to stay away from bi-directional relationships if dimension (lookup)
tables are shared across fact tables. Although the “cross filter direction” property allows
many-to-many relationships and offers more flexibility with respect to filter propagation,
my approach is to use bi-directional filtering sparingly and only when a specific analytical
need has been identified.

How Power BI Desktop Handles Relationships

After doing some experimentation, reading, and talking with people, I've learned these
important things:

 Power BI Desktop will auto-detect relationships when it can (ex: matching column
names and data types). According to this Power BI Support article: “Cardinality, Cross
filter direction, and Active properties are automatically set.”

 Power BI Desktop won’t necessarily create all relationships. If it doesn’t have a

very high confidence what to do, it won’t create the relationship.

 Power BI Desktop will attempt to set the cross filter direction to “Both” whenever
it can – that’s the new default behavior.

 Power BI Desktop may set a relationship to inactive if there is some ambiguity

present.

So, be sure review all of the relationships in your dataset, and don’t rely entirely on the
auto-detect functionality.
How to Create Relationships in Power BI Desktop
There are three ways to create relationships in Power BI Desktop:

My preferred method for creating a relationship is to use the “Manage Relationships”

pane. This allows me to specify the column from each table, as well as the items under
Advanced options including cardinality, cross filter direction, and if it’s active or not.

Second method is to drag one column to another in the Relationships pane. This way sets
all of the advanced options to its default settings. Since I have very specific preferences
for the Advanced options, I tend not to use this alternative as often.
Third method is to use the Autodetect functionality within the Manage Relationships
window. This can be a time-saver, but you still need to verify each one is doing what it’s
supposed to do. Therefore, I tend to lean towards creating them manually so that I’m
certain the data model is specified exactly the way I want it. Since Power BI Desktop does
Autodetect by default, you probably won't need to use Autodetect unless you've deleted
some relationships along the way.
What are Bi-Directional Relationships in Power BI?
Bi-directional relationships have a few aliases. People refer to it as as BiDi, cross
filtering, and/or many-to-many.

When set to “Single,” the dimension (or lookup, from the ‘one’ side of the relationship)
can filter the fact (or base table from the ‘many’ side of the relationship), but it cannot
filter the other way around. That's why the arrow points one direction. In the following
screen shot, this means we can slice and dice the Quantity measure (from the fact) by
Customer (from the dimension). For example: Sum of Quantity by Customer.

This works well for most scenarios when a traditional dimensional model (aka star
schema) is implemented, wherein dimensions contain attributes and facts contain
measures. This facilitates the slicing/dicing in the dimension and aggregation in the fact.
Conversely, bi-directional relationships permit filters to propagate in Both directions (as
opposed to one-way with the Single filter). Under the covers, for filtering purposes,
Power BI Desktop treats the two tables as if they’ve been flattened into one single table.

With the standard “Single” direction relationship as shown above, we could *not* do
something like Count of Customers by Quantity sold – that type of question is moving the
aggregation to the dimension and the slicing/dicing to the fact which is the inverse of
what we usually do. However, the Both setting allows that type of analysis to work.

Sounds like a great idea. Why wouldn’t we want to always do this?

When to Avoid Using Bi-Directional Filtering in Power BI Desktop

If you have more than one fact table in your dimensional model, you want to stay away
from the ‘Both’ setting. I don’t claim to understand entirely how it works under the
covers, but I can confirm that you end up with some inactive relationships that you really
want to be active. As you probably know, an inactive relationship can only be invoked
through a DAX calculation so that limits some self-service BI scenarios.

We have a project with a traditional star schema with 4 fact tables and approximately 15
dimensions (about half are actually role-playing date dimensions). Each relationship from
dimension to fact represents a standard 1-to-many. After migrating the existing model
from XLSX into Power BI Desktop, I was surprised to see approximately 5 of the
relationships were set to inactive in Power BI Desktop. Here is a vastly simplified version
of that data model (reduced to 2 dimensions in this example) to illustrate what I was
experiencing:

See in the above screen shot how some of the relationships are inactive? That’s because
Power BI Desktop detected some ambiguity. Since some of the ‘Both’ cross filter settings
were allowing bi-directional relationships, that caused issues when trying to create
relationships which otherwise are absolutely valid and active. This Power BI Support
article states: “If you have two or more tables that also have lookup tables (with some in
common) then you wouldn't want to use the Both setting.” So, my general rule is to avoid
using the ‘Both’ setting when any dimension (lookup) tables are shared among multiple
fact (base) tables.

Also, be aware that since the bi-directional ‘Both’ setting does alter how filters work,
more complex queries may be sent to the data source. So be sure to test for both
performance and accuracy, and that row level security does what you expect it to do.
The kind of testing we always do anyway, right? Right.
In conclusion, I would like to propose that bi-directional cross filtering should be used in
moderation – If you have a specific analytical need, and if there is one single fact table
sitting in the center of dimension (lookup) tables then it should be just fine to use. If you
see some unexpected behavior, or you see inactive relationships that you don't expect,
the relationship settings are one area to check.

Finding More Information

Power BI Support: Create and Manage Relationships in Power BI Desktop

Chris Webb Blog: Bi-Directional Relationships and Many-to-Many in the Power BI Designer

and One-to-One Relationships in Power BI

You Might Also Like...

Groups in Power BI - How Sharing and Security Works

Direct Connect Options in Power BI for Live Querying of a Data Source

CreCreate and manage relationships in

Power BI Desktop
https://docs.microsoft.com/en-us/power-bi/desktop-create-and-manage-relationships

When you import multiple tables, chances are you’re going to do some analysis using data from
all those tables. Relationships between those tables are necessary in order to accurately calculate
results and display the correct information in your reports. Power BI Desktop makes creating
those relationships easy. In-fact, in most cases you won’t have to do anything, the Autodetect
feature can do it for you. However, in some cases you might have to create relationships
yourself, or you might need to make some changes to a relationship. Either way, it’s important to
understand relationships in Power BI Desktop and how to create and edit them.

Autodetect during load

If you query two or more tables at the same time, when the data is loaded, Power BI Desktop
attempts to find and create relationships for you. Cardinality, Cross filter direction, and Active
properties are automatically set. Power BI Desktop looks at column names in the tables you are
querying to determine if there are any potential relationships. If there are, those relationships are
created automatically. If Power BI Desktop cannot determine with a high level of confidence
there is a match, it does not automatically create the relationship. You can still use the Manage
Relationships dialog to create or edit relationships.

Create a relationship by using Autodetect

On the Home tab, click Manage Relationships > AutoDetect.

Create a relationship manually

1. On the Home tab, click Manage Relationships > New.
2. In the Create Relationship dialog, in the first table drop-down list, select a table, and then select
the column you want to use in the relationship.
3. In the second table drop-down list, select the other table you want in the relationship, then
select the other column you want to use, and then click OK.
By default, Power BI Desktop automatically configures the Cardinality (direction), Cross filter
direction, and Active properties for your new relationship; however, you can change the settings
if necessary. To learn more, see the Understanding additional options section later in this article.

You'll see an error that states One of the columns must have unique values if none of the tables
selected for the relationship has unique values. At least one table in a relationship must have a
distinct, unique list of key values, which is a common requirement for all relational database
technologies.

If you encounter that error, there are a couple ways to fix the issue:

 Use "Remove Duplicate Rows" to create a column with unique values. The drawback to this
approach is that you will lose information when duplicate rows are removed, and often a key (row)
is duplicated for good reason.
 Add an intermediary table made of the list of distinct key values to the model, which will then be
linked to both original columns in the relationship.

For more detailed information, see the blog post.

Edit a relationship
1. On the Home tab, click Manage Relationships.
2. In the Manage Relationships dialog, select the relationship, then click Edit.
Configure additional options

When you create or edit a relationship, you can configure additional options. By default,
additional options are automatically configured based on a best guess, which can be different for
each relationship based on the data in the columns.

Cardinality

Many to One (*:1) - The most common, default type, which means the column in one table can
have more than one instance of a value, and the other related table, often know as the Lookup
table, has only one instance of a value.

One to One (1:1) - The column in one table has only one instance of a particular value, and the
other related table has only one instance of a particular value.

Many-to-many relationships: With composite models, you can establish many-to-many

relationships between tables, which removes requirements for unique values in tables. It also
removes previous workarounds, such as introducing new tables only to establish relationships.
For more detailed information, see Relationships with a many-many cardinality.

See the Understanding additional options section later in this article for more details about when
to change cardinality.

Cross filter direction

Both - The most common, default direction, which means for filtering purposes, both tables are
treated as if they're a single table. Both works well with a single table that has a number of
lookup tables that surround it. An example is a Sales actuals table with a lookup table for
department. This is often called a Star schema configuration (a central table with several lookup
tables.) However, if you have two or more tables that also have lookup tables (with some in
common) then you wouldn't want to use the Both setting. To continue the previous example, in
this case, you also have a budget sales table that records target budget for each department. And,
the department table is connected to both the sales and the budget table. Avoid the Both setting
for this kind of configuration.

Single - Filtering choices in connected tables work on the table where values are being
aggregated. If you import a Power Pivot in Excel 2013 or earlier data model, all relationships
will have a single direction.

See the Understanding additional options section later in this article for more details about when
to change cross filter direction.

Make this relationship active

When checked, this means the relationship serves as the active, default relationship. In cases
where there is more than one relationship between two tables, the active relationship provides a
way for Power BI Desktop to automatically create visualizations that include both tables.

See the Understanding additional options section later in this article for more details about when
to make a particular relationship active.

Understanding relationships

Once you have connected two tables together with a relationship, you can work with the data in
both tables as if they were a single table, freeing you from having to worry about relationship
details, or flattening those tables into a single table before importing them. In many situations,
Power BI Desktop can automatically create relationships for you, so creating those relationships
yourself might not even be needed. However, if Power BI Desktop can’t determine with a high-
degree of certainty that a relationship between two tables should exist, it does not automatically
create the relationship. In that case, you must create the relationship.

Let’s go through a quick tutorial, to better show you how relationships work in Power BI
Desktop.

Tip

You can complete this lesson yourself. Copy the ProjectHours table below into an Excel
worksheet, select all of the cells, click INSERT > Table. In the Create Table dialog, just
click OK. Then in Table Name, type ProjectHours. Do the same for the CompanyProject table.
You can then import the data by using Get Data in Power BI Desktop. Select your workbook
and tables as a data source.

This first table, ProjectHours, is a record of work tickets that record the number of hours a
person has worked on a particular project.
ProjectHours

Ticket SubmittedBy Hours Project

1001 Brewer, Alan 22 Blue

1002 Brewer, Alan 26 Red

1003 Ito, Shu 34 Yellow

1004 Brewer, Alan 13 Orange

1005 Bowen, Eli 29 Purple

1006 Bento, Nuno 35 Green

1007 Hamilton, David 10 Yellow

1008 Han, Mu 28 Orange

1009 Ito, Shu 22 Purple

1010 Bowen, Eli 28 Green

1011 Bowen, Eli 9 Blue

This second table, CompanyProject, is a list of projects with an assigned priority, A, B, or C.

CompanyProject
 ProjName Priority

Blue A

Red B

Green C

Yellow C

Purple B

Orange C

Notice that each table has a project column. Each is named slightly different, but the values look
like they’re the same. That’s important, and we’ll get back to it in soon.

Now that we have our two tables imported into a model, let’s create a report. The first thing we
want to get is the number of hours submitted by project priority, so we
select Priority and Hours from Fields.

If we look at our table in the Report canvas, you’ll see the number of hours is 256.00 for each
project, and it’s also the total. Clearly this isn’t correct. Why? It’s because we can’t calculate a
sum total of values from one table (Hours in the Project table), sliced by values in another table
(Priority in the CompanyProject table) without a relationship between these two tables.

So, let’s create a relationship between these two tables.

Remember those columns we saw in both tables with a project name, but with values that look
alike? We’re going to use these two columns to create a relationship between our tables.

Why these columns? Well, if we look at the Project column in the ProjectHours table, we see
values like Blue, Red, Yellow, Orange, and so on. In fact, we see several rows that have the same
value. In-effect, we have many color values for Project.

If we look at the ProjName column in the CompanyProject table, we see there’s only one of each
of the color values for project. Each color value in this table is unique, and that’s important,
because we can create a relationship between these two tables. In this case, a many-to-one
relationship. In a many-to-one relationship, at least one column in one of the tables must contain
unique values. There are some additional options for some relationships, and we’ll look at those
later, but for now, let’s create a relationship between the Project columns in each of our two
tables.

To create the new relationship

1. Click Manage Relationships.
2. In Manage Relationships, click New to open the Create Relationship dialog, where we can select
the tables, columns, and any additional settings we want for our relationship.
3. In the first table, select ProjectHours, then select the Project column. This is the many side of
our relationship.
4. In the second table, select CompanyProject, then select the ProjName column. This is the one
side of our relationship.
5. Go ahead and click OK in both the Create Relationship dialog and the Manage
Relationships dialog.
In the interest of full disclosure, you just created this relationship the hard way. You could have
just clicked on the Autodetect button in the Manage Relationships dialog. In fact, Autodetect
would have already done it for you when you loaded the data if both columns had the same
name. But, what’s the challenge in that?
Now, let’s look at the table in our Report canvas again.

Now that looks a whole lot better, doesn’t it?

When we sum up hours by Priority, Power BI Desktop looks for every instance of the unique
color values in the CompanyProject lookup table, and then look for every instance of each of
those values in the CompanyProject table, and calculate a sum total for each unique value.

That was easy, in fact, with Autodetect, you might not even have to do this much.

Understanding additional options

When a relationship is created, either with Autodetect or one you create manually, Power BI
Desktop automatically configures additional options based on the data in your tables. You can
configure these additional relationship properties located in the lowest portion of the Create/Edit
relationship dialog.

As we said, these are usually set automatically and you won’t need to mess with them; however,
there are several situations where you might want to configure these options yourself.
Automatic relationship updates

You can manage how Power BI treats and automatically adjusts relationships in your reports and
models. To specify how Power BI handles relationships options, select File > Options and
settings > Options from Power BI Desktop, then select Data Load in the left pane. You then see
options for Relationships.

There are three options that can be selected and enabled.

The first option is Import relationships from data sources, and it is selected by default. When
selected, Power BI checks for relationships defined in your data source, such as foreign key /
primary key relationships in your data warehouse. If such relationships exist, they are mirrored
into the Power BI data model when you initially load data. This option enables you to quickly
begin working with your model, rather than requiring you find or define those relationships
yourself.

The second option is Update or delete relationships when refreshing data, and it is off by default.
If selected (enabled by checking the box beside the option), Power BI checks for changes in data
source relationships when your dataset is refreshed. If those relationships changed or are
removed, Power BI mirrors those changes in its own data model, updating or deleting them to
match.

Warning

If you are using row-level security that relies on the defined relationships, we do not recommend
selecting the second option, Update or delete relationships when refreshing data. If a
relationship is removed that your RLS settings rely on, your model may become less secure.

The third option is Autodetect new relationships after data is loaded, which is described in
the Autodetect during load section, found earlier in this article.

Future updates to the data require a different cardinality

Normally, Power BI Desktop can automatically determine the best cardinality for the
relationship. If you do need to override the automatic setting, because you know the data will
change in the future, you can select it in the Cardinality control. Let’s look at an example where
we need to select a different cardinality.

The CompanyProjectPriority table below is a list of all company projects and their priority. The
ProjectBudget table is the set of projects for which budget has been approved.

ProjectBudget

Approved Projects BudgetAllocation

Blue 40,000

Red 100,000

Green 50,000
CompanyProjectPriority

Project Priority

Blue A

Red B

Green C

Yellow C

Purple B

Orange C

If we create a relationship between the Project column in the CompanyProjectPriority table and
ApprovedProjects column in the ProjectBudget table, like this:
Cardinality is automatically set to One-to-One (1:1), and cross filtering to be Both (as shown).
This is because to Power BI Desktop, the best combination of the two tables really looks like
this:

Project Priority BudgetAllocation

Blue A 40,000

Red B 100,000
 Project Priority BudgetAllocation

Green C 50,000

Yellow C

Purple B

Orange C

There is a one-to-one relationship between our two tables because there are no repeating values
in the combined table’s Project column. The Project column is unique, because each value occurs
only once, so, the rows from the two tables can be combined directly without any duplication.

But, let’s say you know the data will change the next time you refresh it. A refreshed version of
the ProjectBudget table now has additional rows for Blue and Red:

ProjectBudget

Approved Projects BudgetAllocation

Blue 40,000

Red 100,000

Green 50,000

Blue 80,000

Red 90,000

This means the best combination of the two tables now really looks like this:
 Project Priority BudgetAllocation

Blue A 40,000

Red B 100,000

Green C 50,000

Yellow C

Purple B

Orange C

Blue A 80000

Red B 90000

In this new combined table, the Project column has repeating values. The two original tables
won’t have a one-to-one relationship once the table is refreshed. In this case, because we know
those future updates will cause the Project column to have duplicates, we want to set the
Cardinality to be Many-to-One (*:1), with the Many on the ProjectBudget side and the One on
the CompanyProjectPriority side.

Adjusting cross filter direction for a complex set of tables and

relationships

For most relationships, the cross filter direction is set to ‘Both’. There are, however, some more
uncommon circumstances where you might need to set this different from the default, like if
you’re importing a model from an older version of Power Pivot, where every relationship is set
to a single direction.

The Both setting enables Power BI Desktop to treat all aspects of connected tables as if they are
a single table. There are some situations, however, where Power BI Desktop cannot set a
relationship’s cross filter direction to ‘Both’ and also keep an unambiguous set of defaults
available for reporting purposes. If a relationship cross filter direction isn't set to Both, then it’s
usually because it would create ambiguity. If the default cross filter setting isn’t working for you,
try setting it to a particular table or Both.

Single direction cross filtering works for many situations. In fact, if you’ve imported a model
from Power Pivot in Excel 2013 or earlier, all of the relationships will be set to single direction.
Single direction means that filtering choices in connected tables work on the table where
aggregation work is happening. Sometimes, understanding cross filtering can be a little difficult,
so let’s look at an example.

With single direction cross filtering, if you create a report that summarizes the project hours, you
can then choose to summarize (or filter) by CompanyProject, Priority or CompanyEmployee,
City. If however, you want to count the number of employees per projects (a less common
question), it won’t work. You’ll get a column of values that are all the same. In the example
below, both relationships cross filtering direction is set to a single direction – towards the
ProjectHours table:
Filter specification will flow from CompanyProject to CompanyEmployee (as shown in the
image below) but, it won’t flow up to CompanyEmployee. However, if you set the cross filtering
direction to Both it will work. The Both setting allows the filter specification to flow up to
Employee.
With the cross filtering direction set to Both, our report now appears correct:
Cross filtering both directions works well for a pattern of table relationships that look like the
pattern above. This is most commonly called a star schema, like this:

Cross filtering direction does not work well with a more general pattern often found in databases,
like in this diagram:

If you have a table pattern like this, with loops, then cross filtering can create an ambiguous set
of relationships. For instance, if you sum up a field from TableX and then choose to filter by a
field on TableY, then it’s not clear how the filter should travel, through the top table or the
bottom table. A common example of this kind of pattern is with TableX as a Sales table with
actuals data and for TableY to be budget data. Then, the tables in the middle are lookup tables
that both tables use, such as Division or Region.

Just like with active/inactive relationships, Power BI Desktop won’t allow a relationship to be set
as Both if it will create ambiguity in reports. There are several different ways you can deal with
this and here are the two most common:

 Delete or mark relationships as inactive to reduce ambiguity. Then you might be able to set a
relationship cross filtering as Both.
 Bring in a table twice (with a different name the second time) to eliminate loops. This makes the
pattern of relationships like a star schema. With a star schema, all of the relationships can be set
to Both.
Wrong active relationship

When Power BI Desktop automatically creates relationships, it sometimes encounters more than
one relationship between two tables. When this happens only one of the relationships is set to be
active. The active relationship serves as the default relationship so that when you choose fields
from two different tables, Power BI Desktop can automatically create a visualization for you.
However, in some cases the automatically selected relationship can be wrong. You can use the
Manage Relationships dialog to set a relationship as active or inactive, or you can set the active
relationship in the Edit relationship dialog.

To ensure there’s a default relationship, Power BI Desktop only allows a single active
relationship between two tables at a given time. So, you must first set the current relationship as
inactive and then set the relationship you want to be active.

Let’s look at an example. This first table is ProjectTickets, and the next table is EmployeeRole.

ProjectTickets

Ticket OpenedBy SubmittedBy Hours Project

1001 Perham, Tom Brewer, Alan 22 Blue

1002 Roman, Daniel Brewer, Alan 26 Red

1003 Roth, Daniel Ito, Shu 34 Yellow

1004 Perham, Tom Brewer, Alan 13 Orange

 Ticket OpenedBy SubmittedBy Hours Project

1005 Roman, Daniel Bowen, Eli 29 Purple

1006 Roth, Daniel Bento, Nuno 35 Green

1007 Roth, Daniel Hamilton, 10 Yellow

David

1008 Perham, Tom Han, Mu 28 Orange

1009 Roman, Daniel Ito, Shu 22 Purple

1010 Roth, Daniel Bowen, Eli 28 Green

1011 Perham, Tom Bowen, Eli 9 Blue

EmployeeRole

Employee Role

Bento, Nuno Project Manager

Bowen, Eli Project Lead

Brewer, Alan Project Manager

Hamilton, David Project Lead

Han, Mu Project Lead

Employee Role

Ito, Shu Project Lead

Perham, Tom Project Sponsor

Roman, Daniel Project Sponsor

Roth, Daniel Project Sponsor

There are actually two relationships here. One is between SubmittedBy in the ProjectTickets
table and Employee in the EmployeeRole table, and the other is between OpenedBy in the
ProjectTickets table and Employee in the EmployeeRole table.

If we add both relationships to the model (OpenedBy first), then the Manage Relationships
dialog will show that OpenedBy is active:
Now, if we create a report that uses Role and Employee fields from EmployeeRole, and the
Hours field from ProjectTickets in a table visualization in the Report canvas, we will see only
project sponsors because they’re the only ones that opened a project ticket.
We can change the active relationship and get SubmittedBy instead of OpenedBy. In Manage
Relationships, we uncheck the ProjectTickets(OpenedBy) to EmployeeRole(Employee)
relationship, and then we check the Project Tickets(SubmittedBy) to EmployeeRole(Employee)
relationship.
See all of your relationships in Relationship View

Sometimes your model has multiple tables and complex relationships between them.
Relationship View in Power BI Desktop shows all of the relationships in your model, their
direction, and cardinality in an easy to understand and customizable diagram. To learn more,
see Relationship View in Power BI Desktop.

Feedback