Top 10 Best Practices When Making Salesforce Customizations

Salesforce is an ultra-adaptable platform. And whether you’re creating a new Salesforce Customization to meet new needs of your business, or you’ve found a feature that you never knew existed, it’s best to implement these new customizations safely. Here in this article, we’ve compiled the top 10 steps you should follow while trying to get these new features into your Salesforce org.

Get Your System Ready

If you have a new org, there’s going to be a lot of features you’d like to customize to fit your business. And if you’re customizing an existing org, many parts of your Salesforce system may have already been adapted. Either way, what you’re going to customize may affect other existing features in Salesforce. So, you want to make sure that when you do make your Salesforce customization, it won’t have any negative impact.

You’re guaranteed a clean system with a new Salesforce org, but most existing orgs require a bit of work. It’s always wise to make sure your current system is clean before performing any new customizations. Check out our six-part series for step-by-step instructions on how to give your Salesforce org a bit of spring cleaning.

Is It the Right Way?

When a request for a new Salesforce customization comes in, it’s natural to simply jump to a solution and implement it. However, there can be many ways to go about implementing a new customization, and sometimes it’s worth just taking some time to assess your options. Some solutions are simply more adaptable and manageable than others. For example, complex customizations made using standard Salesforce features such as Process Builder or Flows can be easily managed by most admins. On the other hand, a customization made in Apex tends to take longer to adapt and will need a Salesforce developer to manage.

For many Salesforce developers, it can be tempting just to code something rather than build out the same functionality through standard features. However, it’s always a better practice to configure as much as you can using standard features and then move to Apex when there is no other option.

Great Planning = Great Execution

Once you’re set on how you’re going to customize Salesforce, it’s worth getting a plan together on how you’re going to execute and deploy your development.

Making a plan has a variety of benefits. Firstly, it gives you a chance to put down on paper exactly what you are doing, giving you a reference that can be used again down the road. This is helpful both for testing your customization as well as if any development or customization is done in the future that may impact your current customization.

Secondly, a plan allows you to organize and prioritize what customizations you’re going to do and in what order. This is important as a lot of features are dependent on other features, meaning you will need to make some customizations before others. So proper planning will make your customization project as efficient as possible.

Always Use the Sandbox!

As tempting as it may be to just go ahead and make quick customizations in your live org, it really isn’t worth the risk of potentially breaking your system without the ability to roll back. With a sandbox, you can create your Salesforce customizations in a safe environment and test without affecting a single other user or your live system.

You have a few sandbox options, so here are some general best practices on when to use these Salesforce sandboxes.

• Developer Sandbox – This sandbox is great for creating new customizations and testing them out with fresh test data. This is because the developer sandbox is created without any data at all, allowing you to see a very clean system without any preexisting mess of data.
• Partial Sandbox – With a partial sandbox, you get a set of sample data inputted into your system, which allows you to see the effect that a customization may have on your data. This is a really great testing environment, since you can use that actual sample data to test or use it as a template for adding extra test data.
• Full Sandbox – The ultimate sandbox, this is a full copy of your org, so you are able to deploy your new customizations into this to see how it will actually look in your system. This sandbox is usually kept for final testing before deploying to live, as anything added to the full sandbox should be ready for the live org. It’s best to keep this up to date, as in most cases this is the closest thing to a backup you’ll have of your live Salesforce system.

Get the Experts In

There are a huge array of features in Salesforce, and it can be really hard to master the ability to customize them all without anything going wrong. So if the customization you need to make is totally out of your depth, then why not get someone else–more qualified than you–to do it for you?

Although it may seem expensive at first, this solution will often save you money in the long run. This is because there are simply too many cases where features have been implemented incorrectly and affect other existing features in Salesforce, meaning you will ultimately end up having to hire a Salesforce expert to fix everything anyway!

Have a read of our article DIY Salesforce vs. getting a pro for tips on whether it’s best to bring in expert help.

Use Tools to Help

If the Salesforce customization you are planning to make is complicated, you may need some pro tools to help you feel more confident that you aren’t impacting anything in the existing system. Panaya ForeSight for Salesforce supports you in the process of customizing Salesforce. It shows you the impact your customizations may make to other features and also helps you release the new features safely and securely.

Test, Test, Then Test Again

Your new Salesforce customization is going to potentially affect a lot of other users and even features in your Salesforce system. So before deploying it to your live org from the sandboxes we were talking about earlier, you want to make sure that it works properly! As a Salesforce admin or dev, you know how the new customization is supposed to work, so you’ll test accordingly. But proper testing includes various processes to make sure your new functionality works in every situation, even if it’s being used in a way that it’s not designed for.

For some great tips on testing, check out our article on UAT and Functional Testing Tips, because there is more to testing than most people think.

Use Helpful Naming Conventions

A really great way to help your fellow admins and devs is to use naming conventions, combined with detailed descriptions discussed in the next section. There are no “official” Salesforce naming conventions, and many people will have their own style or structure for doing this. But generally there are three key points to follow in order to create a good naming convention for your Salesforce org:

• Be Structured – Your naming convention should follow the same rule throughout your org. This way, each feature, whether it be an object or a process, can be defined and understood clearly. For example, for custom fields you could use object_fieldname__c (opportunity_email__c), or for a process you could use Object – process (Opportunity – Owner automation).
• Be Concise – The simpler the naming convention, the easier it is to not only understand but to implement and increase adoption. So it’s best to have only vital information in the name.
• Be Consistent – Naming conventions are useless if nobody sticks to them. If anything, it only adds to the confusion if some people abide by the rules and others do not. Using the steps above can help make it easier for your users to stick to the rules, but training and a bit of discipline can go a long way too!

Add Details

When performing your customizations, many Salesforce features have an area where you can write a description of the meaning behind the customization. This can really help other admins and developers understand what the feature is for and prevent your customization from being duplicated or changed when it shouldn’t be. This area is also a place where you can log what updates or customizations have been performed to that feature, making it easier to work out if any changes–or what changes–may be impacting another area you are working on.

Help Your Users

A lot of Salesforce fields and features, such as validation rules or Apex, have the ability to display help text. These messages can let the user know if they’re doing something wrong or help direct them on how to best use a new customization. Guidance like this for new customizations will go a long way when trying to get users to adopt your new feature. Helping your users ensures that a customization will be used for the intended purpose as well.

Conclusion

These key best practices will help you safely customize Salesforce to fit your business needs. And with the support of tools like Panaya ForeSight for Salesforce, you can also gain the confidence needed to implement other more complicated customizations.

So get out there and start customizing!

We love to help make sure you can customize and deploy features safely to your Salesforce org, so be sure to check out our other Salesforce blogs for some tips and tricks of the trade!