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?
- 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