Allow more MDA joins than the current three-object limit

Related products: None

I would like to see us be able to join MDA objects more than three levels deep. 





Use case is that since our Company Standard object looks up to the User object, if we have any sort of junction object between the main object I'm sourcing and the Company object it's joining too, then the User object is not able to be viewed.





(There are certainly many additional use cases here, especially when relationships are involved, but this is the one most on my mind right now due to a customer use case.)





I realize this can be solved for in the rules engine using bionic rules, but it present issues in pretty much every other feature that would use MDA, most notably the report builder. Thanks!
Spencer- Thanks for posting this.





Did you mean to say that when you have Company=> Bridge table=> User scenario, you are not in a position to view User object's lookup fields? Technically I agree that we have 3 object limit for MDA joins but looking for the business scenario here for having bridge table between Company and User.





While waiting for more clarity / alternatively, have you tried using Import Lookup option to lookup the User ID (GS Id) while loading to company in Gainsight Connect / S3 connector so that bridge table can be eliminated (IF POSSIBLE)?
Spencer- Thanks for posting this.





Did you mean to say that when you have Company=> Bridge table=> User scenario, you are not in a position to view User object's lookup fields? Technically I agree that we have 3 object limit for MDA joins but looking for the business scenario here for having bridge table between Company and User.





While waiting for more clarity / alternatively, have you tried using Import Lookup option to lookup the User ID (GS Id) while loading to company in Gainsight Connect / S3 connector so that bridge table can be eliminated (IF POSSIBLE)?
Spencer - I had same question/comment as Ashok regarding the business use case here.  (not disagreeing with expanding join availability)
Hi Ashok - apologies if I wasn't as clear as I could've been. The bridge table actually exists between the source object and the Company standard object, not between the Company and the User. 





So in the specific example I've cited, the customer has a table where the unique ID - in this case called the "Customer ID" - is located at a level below the account, and it's possible for an Account to have multiple Customer IDs. 





Perhaps the picture below will provide more clarity. For now, I have just added the CSM Name and CSM ID to the Company object so that they can still assign CTAs; alternatively, I'm sure we could ask them to populate the Account ID on their files, but in this specific case, that's not realistic. 






To clarify Spencer, is the user driven then by the customer id?  So not only are there multiple customer IDs/account but also multiple CSM/Account (or stated otherwise, CSM is assigned at the Customer level not the Account level).  
No, their CSM is assigned at the Account level. So the current workaround I've done is added the CSM ID and CSM Name to the Company Object, which gets the job done.





The larger point remains though (in my opinion), that it would be nice to simply have access to the user object in this case and I'm sure many other cases beyond just this one customer.