Hacker News Reader

Comment by wnevets | Hacker News Reader

has salesforce figured out how to do an arbitrary number of objects yet? For example a customer with as many addresses they want? I was told by very expensive salesforce "experts" that wasn't possible a few years ago. You actually needed to hardcode address_1_zip, address_2_zip, address_3_zip and so on.

View on HN

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.

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.

I've been doing some Salesforce dev for a company for about 6 months and as far as I know, this is really still the case. There are ways to do a type of reference that mimics foreign keys and sql joins, but it is terribly convoluted and therefore confusing.

Reply on news.ycombinator.com