I have a requirement for: 1) A Many-to-many relationship requirement between Accounts and Contacts which will utilize a junction object. 2) There will be a One-to-Many relationship between the Junction object and a new Address object.

So as to avoid conflict issue with the internal structure, I have created the following objects: a) NewContacts b) AccountContacts c) Addresses

Example ERD My question: Should I utilize the existing Accounts object or create a new one?

2 Answers 2


There's a lot of standard functionality built in to accounts, so I suggest you don't build your own. There's already accounts, contacts, and account-contact relationships. Plus, you get things like account merging, mail merges, duplicate management, and so on. Build your address object if you'd like, and associate it to accounts and contacts.

  • Thanks for your input. Because of the Many-to-Many I need with Accounts and Contacts forces me to use a junction object. Using the ERD from link, I cannot see any simple way to embrace and extend the AccountContactRole object, which I think forces my hand - unless I am missing something? BTW Based on your advice, I will definitely use the Account object - Thanks
    – Ian
    Jul 1, 2017 at 1:28
  • @Ian I'm not sure why you need to associate an address to an account-contact relationship. It sounds like you're over-complicating things. Still, if you feel like you really need it that way, go ahead and create your AccountContact and Address objects, and use standard Accounts and Contacts. You'll lose the least amount of functionality that way.
    – sfdcfox
    Jul 1, 2017 at 1:42
  • @ian - will also lose state and country picklists if you use a new Addresses object. Plus - almost every ecosystem application in appexchange presumes addresses in Account/Contact
    – cropredy
    Jul 1, 2017 at 2:14
  • Thanks again @sfdcfox. Just to clarify, and by the way in the many years of business I've never seen this, a Contact is nearly always associated with multiple Accounts often dependent on the day of the week and sometimes time of day! Again I truly appreciate your advice.
    – Ian
    Jul 1, 2017 at 6:00
  • @cropredy You're absolutely right, and it is not something I am happy doing. As I understand it, the Address field type should be available in the Spring 2018 release, something that has been sorely missed. My plan will be to use my own address format and convert the custom object to that when it becomes available. That will reopen options again in the AppExchange. Again excellent advice, you guys rock!
    – Ian
    Jul 1, 2017 at 6:03

Another point could be if you planning to use High volume portal licenses for any kind of portal requirements the way you open up access to High volume portal users is using community sharing sets. Using sharing sets we open up access to those objects which has account or contact lookup based on logged in users account/contact information.

creating custom objects for Account/Contact will create more visibility trouble if you plan to use HVPU now or in the future.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .