Hacker News Reader

Comment by ironchef | Hacker News Reader

Easy enough ... set a related list on the SObject.

So ... if a contact should have N Addresses... create an SObject called "ContactAddress" .. and have a relatedlist from contact to N ContactAddress.

View on HN

This is the correct way to do it, but this also means you are going to add another custom object to "objects needs to be documented and maintained by your team" list.

more importantly, it means one less custom object available based on your license. For example, there's nothing stopping you from making 100 custom object available to Customer Community licensed users. However, with the license you get 10 and when they randomly audit your instance find you at +90 the bill will be shocking to say the least. Pay up or get your instance turned off and lose everything.

"with the license you get 10" Questioner didn't stipulate the license they were on. The SF folks I deal with have enterprise licenses (200 custom objects) because SF supports a core part of the enterprise (the revenue side of things). With that there's a certain set of norms that happen and my suggestion is a simple approach to the problem.

"Pay appropriately and do it the right way"

If you're looking for the cheapest solution or the "just getting by" solution don't use Salesforce or you'll get some nasty surprises.

Is this a new feature or is there a downside to doing this? It's very possible these experts just didn't know but I'm curious.

that feature has been there for at least 6 years (for as long as i've been working with SF). It's the most basic relationship using a custom object.

Yeah .. only real downsides are above: * You have a certain number of Custom Objects you can use which cost $X * There's a maximum total you can have (not to be exceeded) * It's another thing to watch / maintain / document * The land of custom objects and fields can get polluted so .. hopefully you have decent governance in place.

Reply on news.ycombinator.com