31 Oct 2018 | 7 min read
Salesforce is undeniably the world’s best CRM system. There are many reasons for this, one of which being the fact that anyone can extend the functionality of the system by creating Custom Objects and Custom Fields.
However, as with all things, we need to remember the wise words of Uncle Ben:
Salesforce comes with a standard set of Objects: Lead, Account, Contact, Opportunity, Case, Campaign, etc. These form the core of the CRM system that Salesforce has designed and perfected over almost 20 years. I’m sure we can all agree that in that time, they’ve been able to polish their solution quite a bit.
I have known a number of clients to attempt to replace the core standard objects such as Account, Contact, Lead, and Opportunity. Something that I learned from this: It almost always doesn’t work out. The grief outweighs the good. Why doesn’t it work? Read on to find out!
As I mentioned before, Salesforce has been building their core solution for almost 20 years now, and in that time they’ve polished it quite nicely. What I’m getting at is… if it ain’t broke, don’t fix it! Don’t reinvent the wheel! Don’t waste your time building something from the ground up when there’s a built in solution you may be able to tweak instead. This will save you masses of time and allow you to focus on more important things.
Once again, Salesforce aren’t new to the CRM game! They’ve been doing it for almost two decades, and gathered feedback from users along the way. Generally speaking, their solution will work for you if you learn how to use it! Don’t go ahead and build something custom without looking to see if there’s a standard solution or standard object that could do the job for you. Chances are, there will be!
This one is important, and I will reiterate a few times on it because it is the number one issue I’ve run into with my clients who have custom solutions. If you’re looking to integrate with a third party system or use a solution from the App Exchange, and you’re using a custom Lead Object, you will run into issues. Third party connectors and solutions have been designed using a standard set of objects and fields that all orgs have; they know to tap into the existing power of every Salesforce environment to maximise their reach. If you’re using a custom object instead of the standard set of objects, these integrations may not work at all!
Like I said, I’ll be reiterating this point because it is a huge issue for my clients who have custom objects to replace the standard ones. Pardot will not sync out of the box with a custom Contact or Lead or Person Account object. The Connector has been designed to work with the standard objects inside of Salesforce, and comes with a number of custom fields in a managed package for your Salesforce environment to benefit from Pardot quickly and easily. For this reason, we strongly encourage you to use the Standard Objects within Salesforce to make your Pardot experience much more valuable.
Note: We have heard some clients with custom solutions are able to get up and running using a non-standard setup, but we do not encourage this at all as it will come with a MASSIVE implementation cost and huge ongoing costs. You will also not immediately benefit from the three yearly Salesforce and Pardot updates. Once again, we do not encourage using custom objects in place of standard objects for Pardot!
Trying to hit this point home once again because it is so important to understand: there are a lot of things outside your Salesforce environment that rely on the standard schema - including other Salesforce products! CPQ, for example, leverages Opportunities and Products quite closely. You’ll be struggling if you’ve built your own Opportunity custom object! Using Service Cloud with a custom Case object will be similarly hindered due to the lack of Case Escalation Rules, Auto-Response Rules, Assignment Rules, Case Teams… the list goes on, but I think you get the point.
You may need to extend functionality at some point in the future, and you may need assistance in doing so. If you reach out to a certified Salesforce Partner and tell them you want to add to the standard function of the Opportunity object, they’ll likely have done something similar and be able to reduce the cost for you. However, if you have a custom solution then everything they do will need to be built from the ground up with you in mind. They’ll also need to spend additional time learning your basic setup and how it differs to what they are all trained to know.
Save yourself the headache and thousands of dollars, use the standard objects where you can.
As you should be aware, Salesforce pushes three major updates a year (Winter, Spring, and Summer). These contain user suggested changes to the platform, as well as security changes and general innovations from Salesforce. They’ll occasionally roll out a new feature that encapsulates a standard object - for example, let’s look at something as basic as Lead Conversion. Imagine you’re in a world where there’s no Lead Convert function, and Salesforce decides to push this incredible feature out to all orgs in the next major update. Your sales team is over the moon because they’re sick of double entry of data to ‘convert’ your custom leads. You then realise it will be your job to tell them they won’t be benefiting from Salesforce’s update because you use a custom solution that was built in house. Your sales team will not be happy at all, and it will take you weeks to build a custom solution with half the ease of use that Salesforce has built.
Trailhead, in my opinion, is one of the best things that Salesforce have ever released aside from Sales Cloud. Trailhead allows literally anyone to learn everything they want to about Salesforce, including standard features included in the various Salesforce Products. If you have built a custom solution that replaces this standard functionality, you won’t be able to guide your users to Trailhead for training. They may discover Trailhead themselves (quite likely as Salesforce really push Trailhead) and get confused and/or upset as to why the things on Trailhead don’t line up with what’s in your org, and why all of a sudden your custom solution seems more difficult to use because they’ve seen what Salesforce was designed to be.
There are rules within Salesforce that we all know: Every record must have a Name, Id, and Created Date/By for example. Another example is that a Lookup field can only look up to a single object (ie, it will look up to Opportunity only)... but this rule can be broken by Salesforce.
The Person Account is basically a hybrid Account object with Contact fields on it. An Opportunity’s Account lookup field may relate to this Person Account object as well as the Account. A Campaign Member’s Contact lookup field may also relate to a Person Account as well as a Contact. This is not something you’d be able to do if you’re using Custom Objects.
Sometimes, rules are meant to be broken (but only by Salesforce)!
Why have multiple Objects that do the same thing? Why rebuild what’s already been built? Why rack your brain to try and build a solution that Salesforce have already built for you? Why try and replicate a newly released feature for your custom solution?
These questions have the same answer: You don’t! Keep it simple and use the Standard Objects that Salesforce has provided in their solution, and extend those using Custom Fields and other tools if need be. Save yourself the hassle!
