function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Vidya DVidya D 

500 - 800 fields support by Salesforce table

 I was wondering if anyone is really taking advantage of large (500 -800) number of fields supported by Salesforce on each table/custom object. I come across  reluctance from designer / developers  to come out of relational data model concept.  I would like to know more about large application schema design.

SfdcStevenSfdcSteven

Yes, many customers are using >500 custom fields.  Many of the use cases I've seen for the extra fields come from delegated administration combined with record types.  For example, if you have a multi-division company where the team in the US, Japan, and the UK want to reuse the same account record, but have geo-specific record types with each geo team owning those record types and field, you hit up against the 500 limit.  Each individual account detail page doesn't include all the fields usually.

 

-Steven

Peter_sfdcPeter_sfdc
You are right to be reluctant. Don't lose that instinct.

But in the end, because of the multi-tenant model, there do arise use cases where this seemingly large number of fields (though they make someone from a traditional RDBMS background cringe) are necessary.

There is another side of this story: technical debt. I am also sure that there are cases where this large number of fields might, if examined closely, prove to be poor design. For customers whose orgs have been evolving for over 10 years, it is natural that some unnecessary features may have evolved into obsolescence, but still remain either due to reticence on the part of IT to remove something just in case that data is needed, or out of lack of resources to dedicate an entire release cycle to clean up that technical debt.

The moral of the story is that the number doesn't tell the whole story. I would suggest to anyone who ran into this in an existing implementation to ask hard questions and push for clean-up if obsolete features are found. Crappy data makes for crappy user experience, creates reporting inaccuracies, and can in turn reduce user adoption.

So my opinion: don't assume it is either good or bad...just try to find out. And clean up where you can.
Jason CurtisJason Curtis

As a new ISV coming to the platform I see some advantages to making fat tables due to storage charges. If I get dinged for 2k per record no matter the size of the table then it makes it a valid archtectual choice to load in as many fields as possible into as few tables as possible.

j