Last Friday, my colleague told me about a head-scratcher moment that he had with his Salesforce client.
The client had an old Salesforce instance, and there were too many “cooks in the kitchen” over the years. Sometimes these were internal people, other times it was external Salesforce agencies.
The result was the case object had 298 custom fields.
Yes, you read that right. ?
My colleague and I discussed several possibilities of why this happened and how to prevent it from ever happening.
Firstly, some fields were so specifically named, they were hard to reuse. For example, there was a field called “QA Status” and another field called “Status”. Only one field was ever populated at a time, so a single “Status” field would have been better. Using a naming conversation with a low level of vagueness would have also helped.
Secondly, these cooks didn’t consider the long-term impacts of their decisions. Most likely, they didn’t consider they wouldn’t be around forever, and didn’t plan accordingly. Adding things like field descriptions and help text would have really helped here.
Lastly, clients should really be careful about who is designing their Salesforce instance. If you have an inexperienced admin running around, it’s going to lead to newbie issues and bad data modelling. Working with an experienced admin or agency will keep technical debt to an absolute minimum.
The takeaway
Don’t let your case object have 298 fields. Just don’t.