You, the Salesforce Admin, are one of the most important people in your business. You are the guardian of clean data, the custodian of security, and the arbiter of decisions for new metadata. Never for a second should you underestimate the power and responsibilities that lie on the shoulders of the Salesforce Admin! It is your responsibility to safeguard your business by ensuring its data remains clean, organized, and complete at all times.
It’s no small feat – being the (sometimes sole) custodian of your business data is a big deal, and you’ll want to upskill and become better at it every single day. That’s admirable! So to help, I’ve pulled together ten rules that you should follow to ensure you’re setting your business up for success in the Salesforce world.
1. Never Have Too Many or Too Few Salesforce Admins
The System Administrator plays a vital role in the business. To ensure they have the power to do this, they are granted elevated privileges within the Salesforce application.
When it comes to giving a System Administrator those elevated privileges, you need to consider how you do it while being very careful about it. Salesforce’s standard System Administrator Profile has a significant number of powerful permissions granted directly to it, and I’ve seen far too many times when a new Salesforce customer adopts the bad habit of assigning the System Administrator Profile by default, which grants far too much in terms of permissions to those users.
The Salesforce Administrator Profile has some extremely powerful permissions like Customize Application, Manage Users, Manage Sharing, View All Data, and Modify All Data. These are just a handful of the permissions that are automatically granted to any user with the System Administrator Profile – many (if not all) of which you should not be granting to a majority of users.
Salesforce encourages its customers to follow the principle of least privilege to ensure that your users only have access to what they need to do their jobs, and nothing more. This ensures that your users aren’t accessing restricted data, and if their access is breached by an external attacker, then it will limit the damage as well.
On the other end of the spectrum, you also don’t want to have too few admins in your org. Consider the number of users that you have and the number of those users who should have access to a specific subset of those admin permissions mentioned earlier. If you have only one, then what happens if/when they leave the company, or if they are unavailable for a longer period of time? Your org security relies on having not too many, and not too few admins.
According to Salesforce, there is a scale that suggests the number of admins based on the number of users. This baseline gives you a good understanding of how many admins your org should have, and suggests some additional factors that may impact this.
2. Use Permission Sets and Permission Set Groups Instead of Profiles
Salesforce is retiring permissions on Profiles in the near future, which means you should start managing your access through Permission Sets and Permission Set Groups sooner rather than later.
This is because managing permissions has become quite difficult as the Salesforce product has evolved over the years. Profiles are too general, and Permission Sets can be a bit too granular. By using a combination of Permission Sets and Permission Set Groups, Salesforce is empowering its customers to make permission management much easier, more granular, and far more scalable than it was with Profiles.
Notably, this change doesn’t mean that Profiles are completely being replaced. They still have their place as custodians of settings that apply to larger groups of users, such as App Defaults, Record Type Defaults, IP ranges, and Login hours. It’s simply the permission management that Salesforce is trying to simplify for us.
3. Leverage Flow Where It Makes Sense
If you’ve been following my work for a while, you won’t be surprised to hear that Flow is on my list of rules that admins should follow, but you might be surprised by how I say it. Flow is an extremely powerful tool that can be used to streamline and automate business processes, saving your users countless valuable hours.
That being said, it’s important to know when the right time to use Flow is. What I’m not doing is suggesting that you use Flow any time that you need something done to the user interface, or even when you need to perform some sort of behind-the-scenes automation. I am suggesting that you identify the correct time to use Flow, and when there may be a better tool that you can use instead.
For example, if you want to surface information from a Case record about the Account it is related to, you could create a Screen Flow that gets the Account record based on the related Id and displays that information. But is this the best way to achieve this goal? Probably not – you’d be much better off leveraging the Dynamic Forms on a Lightning Page.
Another scenario – when you have two or more collections of data that you want to compare against each other and match a key to a value. Flow could do this, but you’d need to play with all sorts of nested loops to achieve it. It may be easier – if you have the knowledge or access to other Salesforce professionals who do – to leverage Apex for a more complex action.
4. Make Use of Password Policies and IP Restrictions
Your Salesforce data is incredibly valuable to your business, and it is even more important to your customers – their data, and the covenant that you have with them to protect that data, is something that should not be taken lightly. You should provide extensive end-user training to ensure your users are informed about how to keep that data secure, and ensure you’re leveraging all the tools available to you to tighten your security to the maximum.
One of the lowest-hanging fruits in the security space for ensuring your end users are as secure as possible is to set up IP restrictions for those users. You can set up Login IP Ranges on the Profile to ensure users are only allowed to access their Salesforce user from a specific physical location.
You will need to make considerations for when you have remote users who need to access the system. They may need to log in using a VPN (Virtual Private Network) or some sort of MOE (Managed Operating Environment) like Citrix.
Another low-hanging fruit is setting up password policies to ensure strong passwords and passwords that are changed relatively frequently. While you, a trusted Salesforce Administrator, may know that setting a secure, complex password that is changed regularly is one fantastic way to secure your account, it will not be the first thing that most users will consider off the top of their heads.
On top of these two points, you should have MFA enabled in your org already. MFA ensures that your username and password (things you know) are not enough to access your account; you need another factor to get in – an authentication method like Google Authenticator (something you have).
You could even go one step further and leverage a business-wide authentication provider like Microsoft Azure and use SSO to log in to Salesforce, as well as have new users provisioned centrally.
5. Get Users to Tell You Business Requirements, Not Dictate the Technical Solution
This is a common mistake that I see far too often with Salesforce Admins who are just trying to serve their business the best way they can: they take requests for new fields and automations from their users as gospel, rather than challenging the reasoning behind those requests and designing the solution themselves.
A frustrated account executive who just wants an easy spot to capture some additional notes on a Lead may ask for a new Long Text field to be created, and so you do it for them. The next week, they complain that they’re only able to capture one Email field on a new Lead, so you create a second Email field on the Lead.
A month later, they want to be able to capture product-specific notes and personality notes, both in separate Long Text fields, and while you’re at it, they also want to capture new Email fields for their finance team contact and their assistant. Suddenly, you’ve got 5 Email fields, 5 Long Text fields, and frustrated teams not sure where data is captured or how to use it.
The situation above is an extreme one, sure, but I’ve seen similar happen, and it causes big headaches and messy, incomplete, and confusing data. This admin, instead of simply taking the requests of the sales user as instructions, could have challenged the request and tried to better understand why they wanted this.
A better solution could have been to handle this later in the nurturing process (convert to Opportunity first), or leverage related records for multiple Emails, or even take advantage of Notes.
The point is this: while you may have the best intentions at heart, your users are the best people possible at doing their jobs, but you are the best at yours. There’s nothing wrong with asking questions, pushing back, and working to understand rather than just doing as a user asks. Creating a better, more scalable design will always pay dividends in the future.
6. Use Lightning Pages and Dynamic Features Instead of Page Layouts
Salesforce continually innovates and adds new features to its products, creating greater value for its customers. Since Lightning was released in 2015, we have seen a massive evolution in terms of how the user experience behaves and how we configure the tools available to us for our users.
One feature that has stuck around from the Classic days – and has taken a bit longer to filter out – is Page Layouts. Lightning Pages were introduced with Lightning, but they leveraged the fields, buttons, and related lists from the Page Layout for a very long time.
That being said, every feature is eventually replaced, and we’ve seen Salesforce slowly roll out some very powerful tools in the Lightning App Builder in the form of Dynamic Forms, Dynamic Actions, and Dynamic Related Lists.
Dynamic Forms allow you to display fields in sections around your page, and unlike Page Layouts, you can split these into multiple different sections on different parts of the screen. These can be displayed or hidden based on criteria.
Dynamic Actions allow you to pick and choose which Actions should be displayed on a Lightning Page from within the Lightning App Builder, and these can also be hidden or displayed based on criteria.
Last but not least, Dynamic Related Lists allow you to configure a new Related List directly on the Lightning Page rather than needing to do so on a Page Layout first.
Letting go of the past and embracing the future means you can take advantage of evolutions as they happen, rather than struggling with older tools that are not receiving updates. It’s definitely worth reviewing the current Lightning Pages that you have and seeing where you can leverage the newer Dynamic Features. It’s also worth staying on top of the releases as they come out to be aware of the evolutions as they occur.
7. Foster a Culture of Ownership
Adoption is the first step. Ownership is infinitely more powerful than adoption could ever be. When users use the system and take advantage of the platform that has been built for them, they are considered ‘adopted’.
But when they actively engage in the innovation process by bringing ideas to the table, taking ownership over education and championing the system, and protecting the integrity of the customer data, that is ownership, and that is what will have a lasting impact.
The simple reality is that someone needs to own the platform, and it is an extremely important and difficult task to do. It is especially difficult if it is thrust onto Salesforce Admins by executives and left to them to do entirely. It is far better to work with the entire organization and get them involved in the ownership process.
If you can get a key stakeholder from each team to own and lead their domain, this is a great start. That way, any questions can be routed to them first, then triaged and escalated to the administrator if need be. It also allows teams to review new requests together to perform some of that validation that we discussed earlier, before they raise those requests to the administrator.
Overall, it helps not only to lighten the load for the administrator but also to ensure that every team feels a sense of ownership and belonging over the platform.
8. Design, Document, Build, Test, and Deploy
You should already know that building in production is heavily frowned upon for several reasons, but you may not know the best way to operate instead. First, you need to make sure you’re taking the requests of the business on board and then performing the design as a technical specialist.
You should be considering the long-term impacts of any changes that are coming into the system, making sure that your changes follow best practices, and ensuring the changes are scalable.
Remember to build in a sandbox, not production. As you go, you should be documenting. Any business requirements that come in, as well as any business decisions that need to be made after the fact, and the outcomes that are extracted from them. It is recommended that you follow the user story format to capture and refine these.
Before you build, ensure your designs are documented and satisfy the business requirements. As you build, document what you have built and any diversions from the original designs as if you were writing instructions to your future self who has to troubleshoot or make changes to the functionality.
Oh, did I mention this should be done in a sandbox? I’m sure I did. If not, then: Do your build in a sandbox environment to avoid issues in your production environment. Okay, good, glad I mentioned that.
Once you’ve built it, you must test what you’ve built thoroughly before you deploy it to production. You should test that it does what it should do, and also test that it doesn’t do anything that it shouldn’t. You should perform your own testing, and you should involve the business for User Acceptance Testing (UAT), where they test the new functionality against the User Stories you captured earlier.
Finally, once all testing has been completed thoroughly, you can deploy into production (because, as you know, you should be building in a sandbox). Make sure to perform post-deployment testing as well to ensure nothing was missed or changed since your sandbox testing.
9. Backup Your Data
Salesforce, like many other SaaS providers, operates on the shared responsibility model. This means that they are responsible for certain things, and you are responsible for others. Salesforce is responsible for things like maintaining the infrastructure that Salesforce runs on, the Salesforce software itself, and ensuring it is available for its customers globally.
As an admin, you are responsible for your data. Making sure that only those who should have access to it do, and that it remains intact, is a vital part of your role. This may mean putting up guardrails like Validation Rules or access controls to keep your data safe. If in the unlikely event that something does happen to that data, though, you’ll need to be prepared as well.
Just like you would with your computer or phone, you must keep a backup of your Salesforce data. This ensures that if Salesforce goes down, your business data is still available and accessible as required.
If something ever happens to your data – like a breach of security or malicious attack on your data – you’re able to respond and recover your recently backed-up data.
This is one step that many businesses often skip over as they rely entirely on Salesforce’s track record and trust their system to keep their data secure and safe. While I’m not trying to put any doubt on that necessarily, I am encouraging you to take ownership of your data, as this is your responsibility at the end of the day.
10. Minimize Technical Debt, Develop an Audit Schedule
Whenever you’re building in your Salesforce environment, you need to plan for the future.
That being said, things slip through the cracks. Some parts of your build are perfectly modern today, but will be replaced by bigger and better tools in years to come. This is why it is important to develop an audit schedule for your Salesforce org.
You should keep in mind not only the technical aspects when you’re planning your audit schedule, but also the business aspects. Your business requirements will be carefully and clearly defined when you build, but the business evolves and changes over time. Salesforce can and will evolve and change with your business, assuming you keep it in check. Check that the tools you’ve set up still do what the business needs on a regular basis. The reality is that changes in your industry or new compliance requirements will mean there needs to be modifications to your Salesforce org.
Develop a schedule that is reasonable, but consistent. Make sure you’ve got the right business users involved in the discussions, as they won’t just be technical.
Keep your finger on the pulse in terms of the new releases from Salesforce and beyond, and look at how you could leverage these new technologies in place of older ones (Flows in place of Workflow Rules, Lightning Pages in place of Page Layouts, etc).
Bonus Rule: Educate Like the Business Depends on It
Just because you’re the Salesforce Admin, doesn’t mean that you’re the only one who needs to be educated! You should empower your users and other business stakeholders by helping them to learn the system, the Salesforce ecosystem, and where they can go for inspiration for new ways to leverage the Salesforce tool to assist in their day-to-day business.
Educate your stakeholders on all things security so that they can protect their user accounts and the precious data that Salesforce holds. Educate them on new ways that they can leverage the tools they have at their fingertips to speed up their workflow. Educate them on new keyboard shortcuts that they may find beneficial. Heck, educate them on features that you’re not even using yet, just to inspire them and get them thinking about what the system could look like one day.
This all ties back to the ownership point I made earlier – if everyone is informed and begins putting suggestions together regarding system enhancements, the system as a whole is more likely to succeed as the business is carrying it together rather than sitting on the backs of a small number (or potentially even a singular) of admins.
Final Thoughts
If you want to be a successful Salesforce Admin, following these rules will help you along your way. Some of them are straightforward, others are a little more complex and come with additional costs that you could consider carefully.
Seasoned administrators – what additional rules would you share with junior admins? And junior admins, which of these rules do you think will be the most valuable to you in your org? I’d love to hear from you! Drop me a message on LinkedIn, or share your thoughts in the comments below.
Comments: