2

Our organisation is within the Public sector and our Salesforce use will not extend to the Sales Pipeline Standard Objects aspect of the CRM. Instead our custom app will include the recording of different processes against each contact. For example the call types (processes) would be Enquiry, Complaint, Request etc.

I have been struggling to understand/figure out the best design in Salesforce. At the moment the Contact will be related to "Call" custom object which will contain the entire call history via related lists. This in turn will either have a custom object or picklist to determine the "Call Type" of the process. This selection will then make available to the user a form to capture the necessary information for the process, this will be either:

  • one Custom Object with many fields to cover all call types but assign Record Types to ensure only the right questions are asked on the right process.
  • Use many Custom Objects, one for each call type, allowing for a 1-1 relationship between process and custom object.

At the Contact object we will want to report down through call, call type and any other objects and of course summarise data on dashboards/list views.

Does that make sense, I've been struggling to find much information online and within my dev account I have only really got option 1 working and not suitably yet.

I understand this is a design query and if it is too vague I apologies - please advise if it should be deleted.

Improve this question

2 Answers 2

Reset to default
3

I like Option 1 because reporting is so much easier when you have one SObject with many recordTypes. SFDC reporting across sibling objects is very difficult. And, if that is difficult, your dashboards will explode as well into more components than you need.

By way of proof - in my org, which supports a multi-billion$ company, there are obviously many different kinds of sales opportunities as the business is complex and has grown through acquisition. Nevertheless, even with literally hundreds of thousand of opportunities, we have only one Object and perhaps a dozen recordtypes. Reporting across these various sales opportunites is easy as well as reporting within a particular recordtype. There are many shared fields. I can't imagine how hard it would be if we had multiple sobjects -- everything would have to go into a BI warehouse where it was all standardized again in order to do consistent reporting.

Lastly, I think you will find that there are common questions across call types as well as unique questions. Good naming conventions can help differentiate questions by call type (as well as common questions)

Improve this answer
3
  • Our org is essentially local govt council, up to 500 users but Salesforce is planned to be used throughout within a few years - starting in IT, the n customer services (30+ processes) etc etc. It's all customised for local govt as ultimately we don't "sell" like a private sector might. interesting, reporting is a key requirement as well - likley going to be using Salesforce Analytics Cloud to be open, transparent and provide real time results. So 1 custom object, "Call" with record types used to filter fields for the type of call (the type of call would be another object to use slas etc)
    – n34_panda
    Oct 11, 2015 at 10:59
  • Is there a field limit on a custom object, I want to say 255? I imagine we could look at breaking it down to services, for example Business Calls Object, Personal Calls Object etc etc. So much to think about and we don't have long. I appreciate your help
    – n34_panda
    Oct 11, 2015 at 10:59
  • 1
    Depends on Edition (Summer 15) Enterprise = 500; Unlimited = 800. Note with recordtypes, you can tailor the values of picklists so some values appear only for some recordtypes -- this is an excellent way to avoid an explosion of custom fields
    – cropredy
    Oct 12, 2015 at 17:44
1

I think that Option 2 is good as it can be extended for future usecases.

few points in considering custom object than record type.

  • Permissions; Might be easier to set perms on an object rather than a record type
  • Look up; For most object, there is no difference. You can set up the lookup field to have a filter to only show records matching field A, B and C (ex:record type)
Improve this answer
2
  • Thanks, one final thought - On the Contact I would like a related list of "Calls" which would display the Call fields including Call Type. Then on clicking through to the Call Object I would ONLY display the related list of the custom object selected via the Call Type Object lookup - i hope that makes sense. Essentially Contact -> Call is 1 to many but Call to Call Type is 1 to 1 and I would want to hide related lists that don't apply etc. Is this Apex or can I achieve most of it with GUI?
    – n34_panda
    Oct 10, 2015 at 14:48
  • thinking now it's a mix of processes/flows for the answer...
    – n34_panda
    Oct 10, 2015 at 17:30

You must log in to answer this question.

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