![]() The number of reports should be less than the number of users.Each irrelevant field or object is contributing to the combinatorial explosion from the prior bullet. While it’s perfectly OK to have historical objects that are no longer active (but do hold data) and fields that are explicitly marked as deprecated, having hundreds of “mystery fields” just makes things harder to understand and manage. The system should have less than 10 percent unused objects and less than 25 percent “unused” fields.We’ve worked on SFDC systems that had over 500,000 items for a system administrator to maintain. If you have 20 objects with 100 fields, maintaining 10 profiles involves 40,000 check boxes just for read and write privileges - and then there are all the record-type picklist subsets and page layouts. The most pressing issue is the number of check boxes and selectors that need to be maintained for user profiles, as this suffers from what is amusingly called a combinatorial explosion. ![]() These two rules of thumb by themselves seem arbitrary, but the issue is manageability. No object should have more than 10 record types unless there is an incredibly strong reason for it, and the number of user profiles should be less than 5 percent of the total user count.If you have to have several required fields, at least put them “above the fold” in the page layout so the user doesn’t have to scroll a lot during initial data entry. While the fields that are made required on the page work well and don’t have the ugly failure modes of DML constraints, they do annoy users. No UI page (aka “page layout”) should have more than five required fields.No object should have more than a handful of fields with constraints such as ‘required’ or ‘unique value.’ See the arguments against validation rules.Instead write APEX and VisualForce or Javascript to validate data in a more elegant way. Further, the enforcement of SFDC validation rules causes code to blow up in very ugly ways, which is particularly icky when that code is outside of SFDC and integration/communication loops don’t complete. This means users will be prevented from saving incomplete pages, which means they will “fill in the blank” to save the page and unwittingly contribute to data pollution. Validation rules are really useful for data quality and process conformance, but they act as fully enforced constraints on writes. No object should have more than a handful of validation rules (and ideally, zero).Spurious objects mean UI and reporting ugliness, which means even more code. Too often, code or child objects are used instead of clever formulas. At least 10 percent of an object’s custom fields should be formulas or roll-ups.So here, in no particular order, are some rules of thumb we look out for in an SFDC instance, and why they matter: It’s not that any one of these by itself is an explosion waiting to happen, but each of them contributes to technical debt and the eventual budgetary and data corruption surprises. Here are some quick metrics we use when first evaluating an SFDC system configuration for its sustainability and manageability. When my firm is called in to review larger SFDC instances, we often see the proverbial hallway closet, crammed full of stuff that is going to fall out if you open the door more than a crack. Sounds pretty strategic, doesn’t it? Too often, though, (SFDC) has been managed as “just an app” and all the development work has been thought of as “just adding a feature,” without doing a top-down analysis of the consequences for the rest of IT. ![]() Now, because of the number of its APIs and available adaptors, it’s increasingly being used as an integration hub for the cloud. For a decade, has been both a business application and a development platform.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |