When designing a new feature for a client, one of the first questions you need to ask yourself is: should I use standard objects or create custom ones?
Best practices dictate that if you can use 80% or more of the standard data model, then that’s your choice. If it’s less, then consider custom objects.
Case in point: I’m working with a new client who has had several consultants help them over the years. As I analyze their data model, I noticed they have the following custom objects:
- Transaction (which looks a lot like Opportunity or Order)
- Item (which is like Opportunity Product or Order Product)
- {ClientName} Product (which is like Product)
- Tree (which is like Asset)
Transaction is usually created from an ecommerce store. It contains both purchases and donations.
They could have used it as staging object and then created records in standard objects (like Order and Order Product). Instead the’ve overloaded it, and even use it to fulfill the order.
The kicker is that a much older consultant seemed to use standard objects. So they have records in both a custom Product object and the standard one.
Now I need to decide whether to help by making minor adjustments to their existing data model or rebuilt it using standard functionality.
The former approach will produce results quickly, but is like putting lipstick on a pig. The latter approach will simplify their data model and operations, but will cost a significant amount of time and money.
The takeaway
When building new functionality, take a good strong look at the standard data model before going custom. In the long term, it’ll keep your technical debt to a minimum.