Tag Archives: Salesforce Custom Objects

A Design Decision: Case or Custom Object?


The scenario: Your company has established a new business process in which a request must be created by Sales Reps and sent to Sales Support.

Is this best accomplished by using Cases or creating a new custom object?  I’ll list the questions you should be asking to help you arrive at that decision.

More often than not, Cases will win, but it’s important to know WHY Cases would be the appropriate solution and not fear exploring the use of a custom object if it makes better sense.


Does Sales Support usually work other kinds of requests via Cases?

  • If yes, your aim should be Cases if appropriate.

What is the preferred method of creating this request?

  • If these are external users, you could use Web-To-Case.
  • If the request is also very simple and no real data fields are needed, you could use Email-To-Case.
  • If the requests are originated by Salesforce users, you’re looking at a link or button, which leaves both Cases and Custom Object as options.

Does Sales Support have a queue?

  • You can use Cases or a custom object, as both work with Queues.  However,  only Cases can utilize assignment rules.  With a custom object, you’d likely be creating Workflow rules with Field Updates

If Sales Support doesn’t have a queue, do they want requests with certain specific attributes sent to specific people on their team?

  • Both Cases and Custom Objects can handle that, which like the Queue situation are accomplished with Assignment Rules or Workflows/Field Updates

…or do they want to Round Robin assign?

  • There are different ways to approach that, but could be easier within a Case. See one of those ways here

Do these requests many very specific statuses?

  • It’s probably not a deal breaker, and you could figure out a workaround with dependent picklists, but it’s good to note the limit on Case Status is 100 values.

Do they want the ability to define Open & Closed statuses?

  • Just like Opportunity Stages can be Won or Lost, you can set whether Cases statuses are Open or Closed.  Being able to reference “IsClosed” will help you in other areas.

Will there be a Contact record associated to this request?

  • There are a couple OOTB features that Cases have
    • The Contact can receive an email when a  Case is created, updated, or closed.  You may not needing to set up a Workflow/Email Alert.
    • When a Case Comment is created and set to Public and Send Customer Notification, that goes to the Contact on the Case.  …more on Comments below

Does Sales Support want to enter a series of comments on the request? Do they want the ability to dictate which of those should be private or public?

  • As mentioned above, an OOTB feature of Cases is Comments.  Unlike a text box, multiple comments can be created.  They can also be set to Private, Public, or Public & Notify Contact.

Does the manager of Sales Support want to be notified when a request is taking too long to resolve?

  • Cases have another OOTB feature of Escalation Rules.  An easily configurable feature that can escalate a Case to a manager if it’s not reached a certain status in a predefined amount of time.

Is there a need for Sales Support to escalate certain requests?

  • Again, Case Escalation Rules.

Could Sales Support benefit from sharing & storing knowledge used to complete requests?

  • If so, you could use another OOTB Case feature:  Solutions

Does this request require a lot of information?

  • You should be aware of object limits here. The Case object has a limit of 800 fields. If you have a very large organization consisting of many BU’s, it may not be appropriate to ‘use up’ so many fields on for just one type of request. 

Should these requests remain visible for reference on the parent record?

  • If you use Cases, there could be many other Cases on that related list. However, with a custom object you could highlight those requests on it’s own related list.

Are reports important?

  • If custom object, less criteria would be needed on the report.
  • If Cases, you can use “Closed” in a filter to simply report on Open or Closed cases.

What is the security need of the requests?

  • Case
    • You’ll have to work around whatever you have your Org Wide Default set to and may need to create sharing rules
    • You’ll also be ‘stuck’ with the object permissions you’ve given your users for other Cases.  You may need to create other configuration (validation rules, for example) to compensate.
    • You might run into situations where a user has access to a edit field on another type of Case, but for this Case it should be read only.
  • Custom object
    • Freedom to set the Org Wide Default and object permissions specific to this request.
    • Easier to set Field Level Security


Considerations When Adding a New Fieldnewfield



Considerations When Adding A New Field



The Sales division just asked for one new field.  Before you go off to your sandbox to get started, you have some questions to ask.

1) What is the Data Type, Name, Description, & Help Text? 

  • After you know the name and purpose of this field, search the object for existing fields that may already serve the same purpose, but perhaps worded differently
  • Depending on data type and purpose, it might need to be unique, external, or encrypted


2) Is this data already available somewhere else, like the parent record?

  • If yes, why is the same data also needed on this object?   (You should mind object limits)
  • If determined a separate field is indeed needed, would a user ever need to edit it?
    • If yes, create the field
    • If no, create a formula field to display value from parent record (default read only)


3) Who Can Access It?  Who Can Edit It?

  • Don’t expect a list of profile names, you may have to figure that out on your own.
  • Confirm user list with the requestor.  What if a profile contains users who should not see/edit this field?


4) Should this field be required?

  • If so, for all records? Or just on certain page layouts?


5) Is it required for certain conditions?  

  • If yes, you’ll need a validation rule.


6) Should it have a certain format?  Or prevent certain words or characters? 

  • If yes, you’ll need a validation rule


7) Which Page Layouts should it be added to?  And where?

  • Same as profiles, don’t expect your end users to know page layout names, but they should know record types.  You can then find the page layout name by viewing Page Layout Assignments.


8) Are you going to report on this field? 

  • If so, it will need to be added to the custom report types that are in use by the requestor & team.  Otherwise expect a frustrated requestor wondering why they can’t report on their new field.

A Design Decision: Case or Custom Object?