Salesforce case objects are often used widely by support organizations for customer support and by other organizations, such as sales, finance, sales operations, or the IT operations team, to support internal employees. In this article, we will discuss some basic use cases for Salesforce email-to-case implementation and best practices for case classifications.
Case management implementation use case
Various teams within an enterprise typically use emails (shared mailboxes) to manage and track their incoming work which can be simple inquiries related to orders or sometimes issues related to products.
However, when a team grows, emails are not a scalable solution, there is no way to track basic analytics like several issues open vs resolved, and there is no automation for managing these emails or issues. Implementing salesforce email-to-case is the ideal use case for managing these incoming email tickets/issues otherwise managed in shared mailboxes.
Configuration of email-to-case
Email-to-case configuration is very easy to implement in Salesforce. Here is the reference salesforce help article to setup email-to-case (https://help.salesforce.com/s/articleView?id=sf.customizesupport_email_to_case_settings.htm&type=5)
Case Categorization using custom picklist fields
Salesforce case object use typically starts with one or two teams and often grows to be used by multiple teams within the organization. The most common business requirement is to categorize the cases with various hierarchies. This categorization/classification helps the team to run analytics related to these issues. Case categorization can be used to tag these cases to product features, issue/complaint categories and its hierarchy.
This category, sub-categories can be configured easily as a dependent picklist in salesforce. However, as several teams using case management solutions grow, this list of values grows and easily reaches its limit, refer to the salesforce document for picklist limits. https://help.salesforce.com/s/articleView?id=sf.picklist_limitations.htm&type=5
The other challenge in managing these picklists as the configuration is whenever the business team requests adding or removing these categorizations based on business needs, it often ends up as a deployment effort for the IT team which typically goes through a rigorous process of functional and regression testing and deployment process.
These challenges can be overcome by implementing the custom framework mentioned below.
Case Categorization using custom dependent text fields framework
This is a custom lightning web component framework which can be used to build a custom custom-dependent picklist kind of experience with underlying text fields as metadata, the solution consists of the following components.
- Custom Text fields on case object category, and subcategory. If there are multiple-level dependencies then you can add additional custom text fields.
- Custom object to manage salesforce objects (case in this example) controlling text fields and their values, along with dependent text fields and their values.
- Custom lightning web component as a user interface to allow users to select these values. This lightning web component query below the custom object to show controlling and dependent picklist field values. This lightning component can be extended to show multiple levels of field dependency hierarchy with minimum effort.
- The lightning web component can be called from either the custom action button on the case page, or it can be dropped on the lighting record page as a side component for users to update these fields’ categories & subcategories.
Custom Object Definition
| Object Name | Name of the object for which this custom picklist framework is built. Case in this example |
| Object Record Type | Record type of the object, case record type |
| Controlling Value | Controlling picklist field value as self-lookup to this object, category in this example |
| Picklist Field | Picklist field name, category, or sub-category in this example |
| Picklist Value | Picklist field value |
| Read Only | Checkbox to specify if this is the required field |
| Required | Controlling picklist field value as self-lookup to this object, a category in this example |
This custom picklist dependency framework is easy to manage as picklist values are data in a custom object. Permission can be granted to business users to manage this data without being required to do configuration and deployments in sandboxes and production environments. This framework can be extended to any object and can be used for picklist fields reaching the limit.
Conclusion
Salesforce email-to-case is the best way to manage your teams’ shared mailboxes. Case categorization is the best practice to build strong analytics for these cases. When multiple teams start using case management functions, case category and sub-category dependency often reach the limit. It is better to implement a scalable solution like the custom text field dependency framework mentioned above from the beginning otherwise migrating from picklist fields to a custom text dependency framework will be a complex effort.
References
- https://help.salesforce.com/s/articleView?id=sf.aura_overview.htm&type=5
- https://medium.com/@aneudupi/custom-picklist-component-using-lwc-e6014a0de9c5
- https://help.salesforce.com/s/articleView?id=sf.customizesupport_email_to_case_settings.htm&type=5
- https://help.salesforce.com/s/articleView?id=sf.picklist_limitations.htm&language=en_US&type=5
