1

We want to receive orders via API from web to Salesforce. We also want order to be related to lead - so the rep can quickly see that right after he clicks on the lead. The problem is, that there are about 5 different types of orders, each of them has different fields. If that would a single object, it would be a really big one and it wouldn't make sense. Also, if we create 5 different custom object types, it would be a total mess, because for 1 lead, there will be also 4 blank objects and only 1 filled.

Just a different point of view: If this was a OOP programming problem, I would create an abstract order class and then inherit those types from it. Then, there would be an array of orders, which can be filled with any particular type.

Thanks for answer.

Improve this question
5
  • 3
    How different are fields? If they are not very different then you could use record types on a single object named order. And then create a look-up relationship on lead object.
    – Sf_Noob
    Oct 1, 2015 at 19:36
  • Very different.
    – Štěpán Víteček
    Oct 1, 2015 at 19:58
  • 1
    If they are very different then I am afraid you would have to create different objects. Or if possible IMHO use record types with a large set of fields on a single big object. That would be much easy to automate using workflows and triggers.
    – Sf_Noob
    Oct 1, 2015 at 20:12
  • We also discussed this problem on Salesforce Success Community: success.salesforce.com/answers?id=90630000000DJI2
    – Štěpán Víteček
    Oct 1, 2015 at 20:24
  • 1
    I'd go with Jeff on this. Record type is the way to go for this problem
    – Sf_Noob
    Oct 1, 2015 at 20:27

1 Answer 1

Reset to default
3

There are many advantages of using recordTypes for a single "Order" SObject:

  1. You can use the OOB Order Sobject and corresponding OrderItem. These objects will be familiar to many SFDC developers who might inherit your org from your able hands
  2. You get the obvious benefits of page layouts that vary by recordType
  3. Reporting and dashboards get much much simpler as you don't have to know which reportType to look for when building a report. The simple filter on RecordType enables reporting for a given type of order. It is very hard in SFDC to do a report across multiple sobjects when they are siblings
  4. While you didn't disclose details about your application, surely there is some commonality between orders - billTo, shipTo, order Number, order date, PO number. And Line Items would share quantity - SKU - unit price - extended price.

BTW - for some orgs, the OOB Orders feature requires enablement - See Setup | Customize | Orders | Settings

Improve this answer

You must log in to answer this question.

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