5 ms·

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

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.

jbf1001 7y ago
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.
deleted 7y ago
[deleted]
ironchef 7y ago
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.
- csunbird 7y ago
  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.
  - chasd00 7y ago
    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.
    - ironchef 7y ago
      "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.
- wnevets 7y ago
  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.
  - chasd00 7y ago
    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.
    - ironchef 7y ago
      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.

jbf1001 7y ago

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.

deleted 7y ago

[deleted]

ironchef 7y ago

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.

csunbird 7y ago
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.
- chasd00 7y ago
  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.
  - ironchef 7y ago
    "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.
wnevets 7y ago
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.
- chasd00 7y ago
  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.
  - ironchef 7y ago
    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.