Best Practices and Recommendations for New Salesforce Admins (Part Four - Tools)

They say hindsight is a wonderful thing and they are right, we can't go back and do over, but we can share what we have learnt and allow others to benefit from our experiences.

This was my approach to the session I presented at the Admin Theatre at this year's London World Tour. My talk was entitled Best Practices and Recommendations for New Salesforce Admins.

The role of Salesforce Admin brings with it a lot of responsibility, but thankfully also all the tools and support to enable each of us to be successful. When we start our Salesforce journey, however, we don't come with all this knowledge fully formed so here are my recommendations and tools to help everyone make the most of the available features.

For ease I am splitting my tips up into Best Practices, Recommendations, and Tools, and then into Setup, Reporting, and Productivity.

Part one here covers Setup Best Practices.
Part two here covers Reporting Recommendations.
Part three here covers Productivity Recommendations.

This post (part four) covers Tools.

Not every Salesforce Administrator works alongside all the users they support, I would hazard a guess that the majority do not. This means that when a user reports an error, or that something 'doesn't work', it can be very hard to troubleshoot effectively. 

Salesforce's Login As feature is is a life saver as it enables us to carry out a task as the user in question, with exactly their permissions and access rights, and to see the error they see (or not, as the case may be). 

This is also essential when rolling out new features as we can test it logged in as one of each user type and know that it doesn't work just for admins, before we deploy it.

A Sandbox is every Admin's best friend, get in and enjoy the sand between your toes!

It is very easy to generate a new sandbox, simply search for sandbox in setup and follow the instructions to produce your new environment.

Your sandboxes are an essential part of the deployment lifecycle process. As we would never dream of making a change directly into our Production instances, our sandboxes are our playgrounds.

Sandboxes are also where we should carry out all demos and training (with the exception of report writing training). If you have access to either a Full or Partial sandbox then you can replicate the functionality of your live environment with either some or all of your data. If you need to check the expected behaviour of some of your automation, your sandbox is the place to do it. If you want to get your hands dirty building out a new flow or process builder, then head to your sandbox and know that you can test until you are happy, with no impact on your users or customers.

If you are lucky enough to have a team working on your Salesforce instance then sandboxes will enable you to ensure that no one's hard work is over-written by another's deployment as you can pass the changes through your sandboxes and use them as a form of version control.

For more advice on how to use your sandboxes, where to generate them from, and working from Development to QA, to UAT through Staging, and finally to Production, I recommend the Application Lifecycle and Development Management Trailhead module.

It might be due to my data background but I very much consider my Salesforce org as a database and so the inserting, updating, and exporting, of data is something I do a LOT to help keep it shipshape.

The Data Import Wizard is great when you are starting out but when you really want to get to grips with your data, and its underlying structure, then Data Loader is the tool for you.

Data Loader has to be downloaded onto your computer, you do this from the setup menu, by searching for data loader and following the instructions. When you fire it up you need to log on with your user name and password with your security token appended to the end of your password.

With just a couple of clicks you can Export all your Accounts as a CSV file, make a change to some data, and use the Update feature to change the values in certain fields. The process will produce a success and a error file and I advise new users to keep these files as a record of what was changed, inserted, or deleted.

Data Loader provides us the means to mass update and even delete records from our Salesforce org but please use with caution. There is no easy way to reverse your actions so double check before using the update or delete functions. 

Workbench is not an official Salesforce product but it is extremely useful tool to help Admins get under the hood of their org. It is accessed via the browser,  at https://workbench.developerforce.com and not from within Salesforce, unlike the Developer Console (which is for Admins too).

Workbench provides a way for you to query your Salesforce data, metadata, and setup. You can write and execute a SOQL or a SOSL query. Retrieve and deploy metadata. Monitor and troubleshoot deployments or processes. As well as Insert, Update, Upsert, Delete, Undelete and Purge data.

Another very handy function it provides as it allows Admins to set the password for individual users.

One of the things I love best about Salesforce is that it is a platform that can be extended and built upon. We can use the declarative and programmatic tools at our disposal to develop new functionality but we can also use the ecosystem and their expertise and save ourselves some time and money.

The AppExchange at https://appexchange.salesforce.com is a catalogue of applications built by Salesforce partners and members of the ecosystem which we can install into our Salesforce orgs to carry out tasks not covered by the standard functionality. 

Many are free of charge, particularly those developed by Salesforce Labs, but even the paids apps often offer free trails. I recommend you install them into a Sandbox first of all to verify that it does what you need it to do, as well as checking that it doesn't conflict with any of your existing processes.

The Apps could do as little as provide a suite of Dashboards, or as much as providing end to end invoicing functionality. Check it out.

That's it for part four and this blog series.

Part one is here, part two here, and part three here.

The Trailmix I created alongside this talk and blog series is here.