When working with my Clients I’m reminded that part of my job is to sound like your high school gym teacher and drill the fundamentals of Salesforce every day – over and over and over. I tend to keep emphasizing best practices, because as an Admin, you’re going to rely on this foundation of knowledge for almost all your design decisions – now and in the future.
Like your coach, I’m trying to make sure you become a successful Salesforce Admin, have fun, play well with others, do not develop bad habits, and most importantly, keep you from getting hurt (or fired!). So let’s take a time out, huddle up, and go over the basics, yet again – in case you weren’t listening the first time 😉
Rule #1 – Use Standard Objects As Intended (Don’t Go “Off-Roading” With the Data Model)
A mistake I see frequently is that people cram in extra functionality or business processes into a Standard Object where it doesn’t belong. I know that was a bit cryptic, so I’ll give you two examples to illustrate.
I was working with an Accounting Firm last year that had created a bunch of custom fields on the Account object for a primary and secondary contact (i.e. two sets of phone numbers, email addresses, first and last names, etc.). They liked this design because their Users didn’t have to click and drill down to Contact records to see key information.
Sounds great initially, however other issues result when you start “off-roading” the data model. For example the Client could not sync emails with Outlook (because there were no Contacts), and they could not send a mass email from Salesforce because Salesforce will only use the native email field on a Contact or a Lead (not custom email fields).
The second example is an Insurance Broker that had self-implemented and was running their entire process off Lead records (including the sales process) using a large amount of custom fields. Not surprising she was struggling trying to filter through hundreds of Lead records to determine which were prospects, active clients, inactive clients, clients in the sales process, those cancelling their policy, renewing their policy, etc.
When I asked her why she was not using Opportunities to track the sale of each policy and subsequent renewal, she replied she didn’t know about Opportunities. Since she self-implemented, she started using Leads, got traction, and that’s as far as she got configuring Salesforce.
Rule #2 – Do Not Use A Custom Object To Replace The Functionality Of A Standard Object
This could almost be a Part B for Rule #1. If an object is person (contains information such as a first and last name, phone number, email address, etc.) think twice about creating a custom object rather than using the Lead or Contact object. What catches people out when using a Custom Object over a Standard Object is when they want to use other native functionality that’s wrapped around Leads and Contacts – it won’t be available (e.g. Assignment Rules, Mass Email, Web-to-Lead, etc.). Additionally you might not be able to take advantage of AppExchange Apps that are expecting “people” to be Contacts and Leads rather than Custom Objects (Marketing Apps, Dialers, etc.).
In the same vein, if something is a business entity (has a physical address, postal mail gets delivered there, and people work or reside there), could it be an Account and rather than a Custom Object?
Lastly, if there is a potential revenue event, whether from onboarding a net new customer, expanding the relationship with an existing client, or some type of financial transaction that occurs (one time or recurring) – consider Opportunities. Again, there is a lot of native functionality related to Opportunities that you may forego if you create a Custom Object (Opportunity Splits, Forecasting, Orders, Products, Quotes, CPQ, etc.)
Are there edge cases where a Custom Object makes sense for something that could be an Account, Contact or Opportunity? Absolutely. Just remember that Salesforce gave us Record Types for a reason (so we can have “flavors” of records), and as an Admin you should know when to leverage them!
Rule #3 – Understand Data Relationships When Creating Custom Objects
We’re up to Rule #3 and I’m still harping on understanding and properly using the Data Model, so hopefully by this point you realize it’s mission critical to setting up Salesforce correctly. Once you get past how to leverage Standard Objects appropriately, inevitability you’ll start building out your org with Custom Objects to track more information and incorporating additional business processes.
The key here is knowing how to “wire up” new tables in the database so they make sense to users, roll-up information, are reportable, and you can enforce security. There are a couple of key data relationships you need to master. Since I’ve covered them in-depth in other blog posts and ShellBlack WhiteBoard videos I’m just going to list them with links. Each has their advantages and disadvantages. Master these concepts and you can design in Salesforce with confidence.
Rule #4 – Use Workflow Over Process Builder
In the words of Flavor Flav – “Don’t Believe the Hype.” Process Builder IS NOT bulkified, Workflow IS bulkified. So what does “Bulkified” mean to an Admin? It comes down to your ability for your automation solution to scale. Let’s say you have an integration that runs at night that upgrades 100,000 records on an object. If that integration caused Workflow to fire on those 100,00 records, rest assured it will fire as expected. If you had used Process Builder, at some indeterminate point, you will likely hit a limit and Process Builder will stop executing. The next morning you’ll find your org a mess.
(Winter 16 Release Notes p338)
Bottom line, Process Builder DOES have SOQL limits, though the term “bulkified” continues to be erroneously mentioned in the context of Process Builder (even by Salesforce). Because of all this misinformation, the myth that Process Builder is “Bulkified” has unfortunately perpetuated in Salesforce Community and Admins have learned the hard way this is simply not true. I wish Salesforce would be more transparent about which automation tools have limits so Admins can make the right choice for a given scenario, but since limits are not a “feature” of Process Builder, the onus is on the Admin to dig in to understand the risks.
(Winter 16 Release Notes p339-340)
Process Builder is attractive because it can do things Workflow cannot do, and if you have Professional Edition, that’s the only automation option available to an Admin. However, if there is ANY chance that solution needs to scale, you are better off using Workflow or custom code. In my opinion (and one I know that is shared with many implementation Partners), the only use case where Process Builder is safe to use is where only a human will be creating or editing a record (i.e. there will be no mass updates by external systems or methods) and there is no other code running on that object.
Remember mass-updating records can be your Marketing department importing new Lead lists, scheduled Apex jobs, integrations, or an Admin updating records with the Data Loader – be careful!
Rule #5 – Salesforce Is Not An iPad – Keep AppExchange Apps To A Minimum
First off, I’m a big fan of the AppExchange, but as an Admin, installing an App in Production should only be done only after the App has been thoroughly vetted in your Sandbox. Also, if you’re no longer using an AppExchange App – uninstall it!
Just last month we were talking to a freight company that was having errors editing and saving Opportunities. Come to find out they had 42 AppExchange Apps installed in their org! Downloading an App off the AppExchange sounds innocuous at face value, but each App potentially has code trying to do a specific purpose in isolation of all other Apps. As with this customer, it is possible to have “code collisions.” It’s not the AppExchange vendor’s fault – the author of one App could not have anticipated the actions of another App – but it shows that a proliferation of code can have a detrimental effect to your org.
Again, as an Admin you want to create an org that is resilient – and that means the absolute minimum amount of custom code running in your org as possible (whether code internally developed or by a third party from an AppExchange App).
Rule #6 – Document Your Org As You Go
You may be a “solo Admin,” but you can still document as you go. In your org, every description field on a Custom Field, Workflow Rule, and Report should be filled in with as much detail as possible. One day you will be gone and someone will need to know the “why” and these breadcrumbs you left behind in the org will be invaluable. Even in our own org, I leverage these little documentation “nuggets” all the time to quickly figure out how processes work that were built years ago.
Rule #7 – Protect Your Users From Themselves
You have Custom Profiles for a reason – use them! Even Professional Edition has two Custom Profiles, so there is no excuse not to “right size” what a user can do in the system. I’m of the opinion that the “Standard User” Profile provides way too much ability for a User to get themselves into trouble. Do you really want Standard Users mass emailing Contacts and willy-nilly deleting closed-won Opportunities?
When we scope out a new project we always recommend creating Custom Profiles. The goal here is to let Users do their job – but nothing more!
Rule #8 – Know What Happened To A Record
Field History Tracking should be enabled for all objects. I like tracking fields such as email addresses and phone numbers on Contacts and Leads, because inevitably someone will change the contact information on the wrong record (oops!), and at a glance we can check the Field History to see the previous value and be able to change it back. If not enabled, that User is going to call you, the Admin, and you’re answer is going to be: “Sorry, I don’t know the cell number of your biggest client!” (or see Rule #9).
Secondly, someone is going to ask you, the Admin, what happened with a record and the “Last Modified By” system stamp is not going to give you the whole story. Now granted Field History Tracking has limits, but it will give you a fighting chance to come back to your boss and tell them, “on this date this user changed this information and on this date the integration changed this information.”
It’s easy to setup in your org and it can save your bacon – and we all know Admins love bacon!
One other quick customer story to reinforce the benefit of enabling Field History Tracking is that it keeps people honest. I had a Client that wanted us to build this elaborate “tattle tale” system in their org so they could be alerted when a salesperson changed ownership of an Account. My suggestion was just to enable Field History Tracking, track the Owner field and put the Field History Related List on the bottom of the Account Page so everyone could see if the Account owner was changed. Sure enough, having that audit trail out in the open was enough of a deterrent. The problem of people swiping Accounts quickly dissipated because Users knew they’d get caught!
Rule #9 – Plan For The Worse – Backup Your Org
If you’re lucky enough to have Enterprise Edition or higher, you have access to the Weekly Export Service. Unlike the Field History Tracking option discussed above, this is a disaster recovery option. For example, a User deletes a bunch of Opportunities on a key Account a few months ago (and recovering from the Recycle Bin is no longer an option), or an integration stopped working last month (and no one noticed), so now you need to reload the data in a set of Custom Objects in a state they were a month a go as a recovery point so you can restart the integration.
The service can be scheduled, which is super handy. I typically exclude Files and Content versions from my backups and focus on records to keep the zip files relatively small. As a best practice, before you run a new integration in production, or deploy a bunch of new custom development, it’s a good idea to back up your org – you know, just in case 😉
Rule #10 – If You Are New To Salesforce Start In Lightning
If you just purchased Salesforce, since you don’t know what you might be missing with Classic, start in Lightning. At this point in the game Lightning has so much momentum, starting in Classic would be a disservice. Is implementing Lightning harder and more time consuming than implementing Classic? Yes. As an implementation Partner that has done both, I can say unequivocally Lightning takes considerably more time to configure, write reports and dashboards, and train end users. However, starting in Lightning is far cheaper than implementing the Classic User Interface only to migrate to Lightning User Experience later.