Many to many relationship on the same Table not displaying in subgrid.

[AJCH]

Hi,

I've got a many to many relationship between the same Table(Intellectual property <=> Intellectual property) as they can relate to each other and can relate to multiple of each other.

Using the main form, I was able to add a subgrid that shows the related entities using this many to many relationship, but it only works 1 way.

For Example

• Intellectual property-123 relates to Intellectual property-ABC via this many to many relationship
• This relationship was created via the subgrid in the main form on the Intellectual property-123 entity
• The Intellectual property-123 subgrid will show this relationship
• The same subgrid on Intellectual property-ABC will NOT.
• However, if I navigate to the Related tab and select Intellectual property it will show the connection to Intellectual property-123 from Intellectual property-ABC

Questions

1. Is there a way where the subgrid on ABC always shows the relationship to 123? It seems that this functionality works when doing a many to many relationship between different Tables but not the same.
2. If not, i'm happy to add another tab based on the subgrid thats automatically generated under the Related tab. But i'm unable to find what view it's looking at.

It's a bit of a complex situation and I hope I explained it well enough. If not I'm happy to clarify.

[dpoggemann]

I have not had to deal with this exact business case but one way to handle would be to add an intersect table in between and then you will have 1-Many from each.  Just a thought to work around...

thanks,

drew

[AJCH]

So you'd have a setup like

IP <-> Intersect table <-> IP

And in the IP entity, maybe a subgrid  that points to the intersect table? 

I guess you would have to create the intersect data entry every time you wanted a many to many? I think that might be a bit cumbersome for the end users. 

Not really related to my issue, but I think the many to many relationship actually does this in the background for you as well. I think the issue is a hiccup / bug since it seems to work normally for other many to many relationships.

[dpoggemann]

Agreed, it would work around the issue but if you really don't have any "fields / data" on the intersection it is not really the best solution.

Thanks,

Drew

[Fubar]

Your issue is that there is actually two relationships (doing a manual N:N will not solve the issue).  The native many to many still creates an intersect entity (you just don't see it in the interface) and you end up with 2 related entities tiles in the navigation (if using a model driven app). 

Behind the scenes the intersect entity has a lookup to record A and another lookup to record B.  To get what you want you would probably need to write a second record (workflow, or flow) reversing the lookup values.  Now if you don't really need an N:N then you can do a recursive 1:N which behaves how you are thinking (assuming hierarchy settings are not configured on the entity),

One alternative to the N:N is to use Connection Roles (this can be configured so when the relationship is set in one direction, the relationship the other direction is also set) - but this is more cumbersome for uses to use.

[AJCH]

---

@Fubar wrote:

Your issue is that there is actually two relationships (doing a manual N:N will not solve the issue).  The native many to many still creates an intersect entity (you just don't see it in the interface) and you end up with 2 related entities tiles in the navigation (if using a model driven app). 

Behind the scenes the intersect entity has a lookup to record A and another lookup to record B.  To get what you want you would probably need to write a second record (workflow, or flow) reversing the lookup values.  Now if you don't really need an N:N then you can do a recursive 1:N which behaves how you are thinking (assuming hierarchy settings are not configured on the entity),

One alternative to the N:N is to use Connection Roles (this can be configured so when the relationship is set in one direction, the relationship the other direction is also set) - but this is more cumbersome for uses to use.

---

I think this is probably the best bet. However, I don't see in Power Automate or in the Background Workflows area a way to trigger when a new relationship has been added to the record. Since Update Record won't trigger I believe because we're actually modifying that intersect table?, and I don't see a way to look at that intersect table via flow either.

EDIT
I've tried pointing the Create, Update or Delete flow to look at the intersect table, which in my solution is crXXX_related_ip but it seems that when adding a new relationship on this many to many table nothing is triggering via flow. 

[Vernhout]

I have a similar use case. You can change the labels of the many-to-many in PowerApps - solutions - classic view. Doing that makes it quite easy to see both parents and childs in Dataverse data relations by choosing the right label. 

However, I did not success to follow these steps in PowerApps. It does not seem to use the modified labels and thus always looks the same way. I agree with you that the datamodel does the job smoothly, but programming on this model is difficult. If someone can point me in the way of handling modified labels in PowerApps that would help. 

[Fubar]

Not sure if you can get it in flow or not (definitely can't in Workflow on a native N:N, would need to make it a manual N:N - create the intersect yourself). For a native N:N Would normally do it via a Plugin, for a native N:N it is an associate or disassociate message (rather than create/update). 

[AJCH · Accepted solution]

Just to help anyone else that finds this thread. What I eventually decided on was a Power Automate Flow that is manually kicked off by the user after they had established their many to many relationship. I've also provided screenshots of the flow that was built to do this. 

Here is a cliffnotes version of what this flow does:

---

I used List Records flow function, directing it at the hidden 'middle' table (in this case, CRXXX_related_ipset) to get two lists of relationships - one of all relationships where the IP was the 'source', and one of all relationships where the IP was the 'destination'.

Note: The main table is called IP, the relationship table is called related_ip but the middle 'hidden table' is called related_ipset

I looped through the 'relationship-source' list and compared it to the 'relationship-destination'. If there was a relationship that went only one way, I created the reverse of it.

---

[AJCH]

Here is the final screenshot, since you can only have 3 attachments.