I work at a mid-size credit union where we use the Case object to handle a bunch of different scenarios (members calling in for support, inter-department requests, etc...). We have created 29 different records types and the Type field is used for various sub-types among those 29 record types. All of these different Case types/sub-types require entering different information and we are nearing the limit of 500 fields on the Case object. Obviously there is some tech-debt here and a review of how we're using the Case object is a necessity. We have analyzed fields and there are duplicative fields or fields we can eliminate, but not enough for this not to continue to be a recurring problem as new Cases are needed by our organization.

That being said there doesn't seem to be a great solution to this issue. Some we have thought of:

  1. Break fields into "field groups" and move them to child objects. The major downside to this in our org is that we have > 1.3 million Case records in our org so this will cost us a lot of extra storage (yes, we could think about archiving too).
  2. Break record types into separate objects by different departments. For example Dept #1 Case, Dept #2 Case, etc... This doesn't feel right conceptually because they are really all Cases.

In each of the above cases, we'd create a Screen Flow to create a Case in order to abstract away the underlying infrastructure from our users. This approach seems like it might be hard to maintain and just move the tech debt to this Flow.

Other off the wall solutions:

  1. Store structured data in a large text field. Then develop an LWC for the record view to parse out into different "fields." The downside to this it would eliminate reporting on specific fields.
  2. Haven't brainstormed too much on this one, but trying to think of a way we could store data outside of Salesforce and pull it back in as needed.

Just reaching out to see in anyone has ran into similar issues and how they solved them?

  • I should have noted that upgrading our edition to get 800 fields won't fit in our budget. Aug 21, 2023 at 17:02
  • 1
    You may find that a parent object makes a lot more sense than child objects to move fields onto. That way, each Case can only have one data container related to it.
    – Adrian Larson
    Aug 21, 2023 at 17:12

2 Answers 2


This is the kind of issue you solve by saying "no" to requests from the business to add fields for the smallest things.

You'll only need to create a field if you need to segregate it from the rest (for security or reporting reasons). Otherwise, your users could probably throw the information in a unstructured note in a text area field, for example.

This is a tricky question because it relies not only on experience but also on people's opinions on the matter. I, for one, think you might be better off archiving some of your data and creating new fields only if they meet the criteria I mentioned before. An effort should be put in tracking and eliminating fields that are no longer used as well (and properly backing up this data and/or moving it to a different field).

I had a similar situation recently where an old implementation we had had four different text area fields effectively acting as the Description field of the case. We retired most of those fields and hid them from the layout, and are working on removing the fields from the system. We don't have heavy compliance regulations on us, so we might be able to just remove the data altogether, but in your case you should look into archiving this.


It sounds like you should look into your type/subtype fields. In theory you should only need 2 and then make the values available by the record type. If you're making new picklist fields just to separate them by the layout or record type then that's a bad design.

Our Case object is at 292 across 16 record types which is a lot but 500 seems like you're duplicating things.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .