Is it best practice to exploit Cases object for multiple use cases beyond change mgt/defect mgt?

Question

My org is looking to utilize the Cases object for various possible uses... such as,

• Internal change/defect management
• Internal EPMO proposals
• Managing certain customer processes or "tracks"

My question is, while all could benefit from the cases structure, is there an issue in having them all share the same object, separated by record types?

Thanks in advance.

Regards,

Answer 1

In general, you should choose to leverage the existing object that most closely aligns to your intended use. For this specific question, it's probably ideal to have all three purposes served by cases, since you get escalations, assignment rules, suggested solutions, and everything else that goes with cases.

Using record types for this purpose is mostly ideal, since you get dependent layouts (show just the fields you need), dependent picklists (show just the values applicable to various types), and so on. And, of course, you can route by record type. Things get a little tricky when talking about record types, and there are some limitations, of course. For example, users can't mass edit cases that are in a list view not filtered by record type.

Ultimately, it's up to you to determine if the tradeoffs are acceptable (and they usually are!). You might find some other features better suited to some purposes, though. For example, while I have no idea what EPMO proposals are, that may be suited to the use of Ideas instead of cases. Change and defect management is almost always best served by cases, but if it's not flexible enough, or you feel there's too much overlap, you could always use a custom object or two. There's no shame in that, either.

Customer-facing elements are probably best served with Cases, though. You can eventually get up to using the Customer Portal to even allow them access to their records directly, for example, and check on the status of their tracks. For internal projects though, Ideas allow voting, have status values, and can certainly have data attached to them, so this might work well.

If you're truly uncertain, I would recommend hiring an expert that has exposure to many different processes (i.e. a consultant). Of course, it'll cost you, but if that means improving processes and making the most of the platform, it may be a worthy investment.

In most cases, I'd suggest you start with a mockup in a Sandbox, so if you don't like it, you can scrap it and start over. Once you're satisfied with the sandbox prototype, give to some users to see if they like it, then migrate the results to production if it's acceptable.