+ Start a Discussion

General Junction Object / super related list


I've found an app in the past that I can no longer recall. Please help me find this app.

It was a fantastic idea: someone had developed junction object that could reference any object.


Salesforce uses a uniform object naming scheme (the object ID). Which the app leveraged to link to a custom object. Other objects related to that custom object aswell. which in fact allowed a connection between any two objects.

Can anyone remember that app? anything even close? 

Your help would be much appreciated.



Cory CowgillCory Cowgill



I would be very cautious, and pretty much flat out reject this type of model.


I'd suggest reading the Developer 401 documenation on creating object relations for lookups and master details.


MD (Master-Detail) and lookup relationships are what create those nice related lists on standard page layouts which admins can modify through clicks.


In addition, MD allows critical functionality like Security, Sharing Rules, Auto-Deletes on Parent, and Roll-Up Summaries to be used with Junction Objects.


Any type of "Super" related list which bypasses this functionality would probably be heavily customized Apex Code and Visualforce to give the "Appearance" of a Super Related List, but would break all DB level functionality. Reports in Salesforce would not recognize these relationships. You wouldn't be able to do Forumlua Fields or Rollup Summaries on the records. Queries would not be indexed on the field because its probably a String field holding some ID. All sorts of issues could arise because you've in effect circumvented the standard Salesforce data model.



Cory CowgillCory Cowgill

I think what you really want the Polymorphic functionality that Events, Tasks, and Attachments have where you have one lookup field called WhatId or ParentId, but you want that for Custom objects. Unfortantely Salesforce doesn't support that.


I've looked high and low for a way to relate a Standard Object to a Customer Object via an External ID field. Many answers in various places alude to this, but I haven't found any comprehesive answer.


This thread seems interesting and related.


My objective is to relate records in a Customer Object to Account Records in a Accounts Object (using a Person Account model) via a master key which is NOT the name field or the Salesforce ID (which appear to be the only options).


The reason for this is that I want to import and sync the records from an external system (manually, but on a on a regular basis for the time being) and I do not want to hold the Salesforce ID in the external system, as that wuld be very awkward to manage and would defeat the whole point. Note, I will be importing and syncing both the Account records and the records in Custom Object.


Relating this to the first point and response in this discussion, I can understand why there is this limitation, as a whole load of functionality must depend on this relationship, but surely so many organisations need to do a similar thing?


I have seen this response, which alludes to a work around.


In Salesforce, the relationship is defined by Look ups or Master details but there is no way you can mark them as External Key Id's. You can mark any of the Custom field as the unique record identifier from an external system but not the relationship field. Unfortunately that is the Caveat we have to live with. There is a work around though, create a field on the Child record to get the ID of the Parent Record and mark that as an External id. Then use a Trigger to populate that field. Hope this helps.


There is also a second point which apparently describes a means to do this, but neither make sense.



I am really surprised I can't find more explicit documentation about this. Please can someone point me in the right direction, or provide a clear, compreneshive answer?


I am sure that there are a whole load of SFDC admins who are trying to get to grips with this fairly fundamental point.


Any help appreciated. And apologies if this isn't the right location, but I've spent days trying to get my head round this and find suitable documentation.