Apex Code Development You need to sign in to do that
Don't have an account?
Unique Properties of Cases?
What functionality of a Case cannot be recreated in a Custom Object?
I'm considering migrating some of our Case Record Types to Custom Objects because of limitations on history tracking, long text fields and just general management. I've been trying to evaluate what I stand to lose in doing so, or at least what would be signifigantly more time-consuming to replicate.
Off the bat, Support Processes. It seems to me a history tracked picklist would provide the same capabilities. Would Durations still be available in History Reports?
Auto-Response, Escalation and Assignment Rules: We don't use these for all Cases, so they won't be missed.
Email-to-Case, Web-to-Case: Maybe someone out there knows how to replicate these. I don't. But then again, don't need them for all Cases.
Since the Case Record Types I'm considering migrating are used internally only and don't get passed around as much, it seems like a safe migration.
I'd love to get other admins' opinions on what makes a Case a Case....
Thanks!
I'm considering migrating some of our Case Record Types to Custom Objects because of limitations on history tracking, long text fields and just general management. I've been trying to evaluate what I stand to lose in doing so, or at least what would be signifigantly more time-consuming to replicate.
Off the bat, Support Processes. It seems to me a history tracked picklist would provide the same capabilities. Would Durations still be available in History Reports?
Auto-Response, Escalation and Assignment Rules: We don't use these for all Cases, so they won't be missed.
Email-to-Case, Web-to-Case: Maybe someone out there knows how to replicate these. I don't. But then again, don't need them for all Cases.
Since the Case Record Types I'm considering migrating are used internally only and don't get passed around as much, it seems like a safe migration.
I'd love to get other admins' opinions on what makes a Case a Case....
Thanks!
There is so much you would miss. Here are a few items:
1) History tracking and long text field limits are the same for custom objects and cases.
2) Cases have a special dispensation for how they are exposed in the Self Service Portal, allowing an agent to own the case and the contact to 'co-own' the case in SSP.
3) Assignment rules
4) Escalation Rules
5) Special consideration in workflow
6) Solutions associated to Cases have a special meaning in the system
7) Suggested solutions are tied to Cases and Solutions, this functionality is not available on custom objects
8) Case lifecycle reports, which provide duration and soon business hours duration, do not have an equivalent in custom object world - of course you could write your own using Apex Triggers but it will not be easy
9) Public comments and Public activities on Cases are not available on other objects
10) Case close process is not replicated in other objects but could be hand coded with Javascript
While you can certainly code around many of these, it will take some commitment and time. I welcome your thoughts and encourage you to explore your approach.
As I examined each Type, I noticed that two or three of them are primarily internal processes that are more geared towards capturing static information than about diagnosing, researching and resolving.
One of the key advantages I see to replacing those two or three with Custom Objects is that it's so much easier to correlate other objects with a Custom Object. You can add whichever look-up fields you want (we need to tie Cases directly to Opportunities) which makes reporting much easier.
However, as I run into hurdles, I'll be sure to post them here for everyone's benefit.