Salesforce Picklist values, as most people who make changes to the Salesforce platform will know, are the subject of many change requests and updates made to the system. These also include workflows, fields, and custom objects. However, even when making a change looks simple and straightforward on the surface, there can often be occasions where the situation becomes more challenging. Maybe you can’t complete your new update, as it’s referenced in some unknown object or code; or a change you made a month ago suddenly stops everything from working.
We’re going to talk about how you can manage your changes to prevent such issues from occurring and how a tool like Panaya’s Release Dynamix for Salesforce can help you do just this.
Managing Salesforce Picklists
Believe it or not, Salesforce custom picklists are one of the most complex and underutilized features of Salesforce. At its core, a picklist is a simple dropdown menu of options, and this is the main way people use it. However, if you don’t know how a picklist has been set up and what it’s connected to, the other features and settings tied to it can make a picklist very difficult to manage. This is one area in which Panaya’s Release Dynamix for Salesforce (RDx) is a great help. It shows you exactly what your picklists are connected to without needing to go hunting through all the different features that may or may not be connected to your specific picklist.
There are three different types of picklists available in Salesforce:
- standard picklists
- multi-select picklists
- global picklists
It’s important to know which one you are dealing with because each picklist field works slightly differently and will have a different impact depending on the changes referencing them. Let’s take a look at how to manage picklists along with some features to consider that affect them all.
You might also like our blog
Managing Salesforce Sandbox Changes in Production
Your Salesforce picklists are made up of a list of options or “Picklist Values.” As your business changes and grows, these picklist values may very well need to be updated. There’s nothing wrong with directly editing values if there is just a slight name change. But you should still consider if that value is also referenced elsewhere, which we’ll talk about in a moment. You should also keep all values you are removing or replacing active—at least until you have completed the following steps. When you’ve created your new values, you then have the option of replacing any records that use the old values with the new values you’ve created.
Dependent picklists are a feature where options from one Salesforce picklist directly influence another Salesforce picklist. Because of this, whenever you need to change picklist values, you will need to manage any dependent picklists that you’ve set up. If you don’t, you may find your new values don’t appear since they weren’t assigned as a dependent value.
Objects in Salesforce have the option of being assigned multiple record types. Record types work in a similar way to dependent picklists when it comes to managing picklist values. When you’re making changes that affect picklists and their values, you’ll need to make sure you have assigned the correct values to the relevant record types as well. Otherwise they simply won’t appear—even if the values are active!
Many Salesforce orgs will have integrations with other systems, whether it be marketing or ERP. These systems will have their own setup, fields, and picklist values. So if you make changes to your Salesforce picklists, you may need to consider if this will impact any of your integrations. Your new Salesforce picklists values may not match up with the values in the integrated system; and if your picklist is set to restricted, it’s highly likely you will get a system error. To prevent this, you can either make your values match or turn off the restricted picklist setting.
Managing Workflows and Process Builder
Although Process Builder is taking over the job of Salesforce workflows, you will find that managing the changes to them is almost exactly the same. As you know, workflows and process builder are automation tools, so they will reference specified fields or actions in Salesforce, which then drive an activity of some sort.
Because of this, when performing changes in Salesforce and workflows, there are all sorts of things that can be impacted. Identifying the impact is the first and most important step. And the easiest and safest way of doing this is using a tool such as Panaya’s RDx. RDx tells you exactly what the workflow references and what other features might be impacted by the automation.
Process Builder has a version control feature that makes it easier to manage each new change. This means that you can roll back to a previous version of the process if you get an error with your current version. Unfortunately, error messages are often hard to decipher, and it can be difficult to understand which feature your process is impacting as well as whether it is your process or another feature that is causing the issue. RDx makes managing your errors a lot easier by showing all the Salesforce features connected to your process and where the errors come from.
You might also like our blog
Salesforce Project Management – DIY Changes vs Hiring a Pro
Fields & Custom Objects
Most Salesforce orgs will have a fair number of custom objects and even more custom fields. As you make changes to your system, both can be impacted and need managing alongside your changes. Objects serve as the backbone of Salesforce, setting the table and structure of the database. They also have a lot of features connected to them. So you need to understand the structure of these objects and the fields that sit beneath them.
Salesforce does have a mapping function, but it isn’t particularly clear, especially if you have a fairly customized org. RDx has a far better mapping feature, allowing you to clearly see objects, fields, and what they both connect to. With this visibility, you can also understand how any objects and fields have been impacted by your change and thus properly manage them.
Salesforce objects and fields (e.g. lead source, trademarks held) have API names, which are referenced in APEX code and integrations. So if you are making changes to the name of the objects and fields, you should leave the API name alone. Otherwise, you may find you start getting errors in your integrations and code.
You might also like our blog
Top 10 features of Salesforce Winter ’19
Managing a Salesforce system can prove challenging at times. But by managing your features and understanding how they are connected, it will become far easier. This is why having a tool such as Panaya’s RDx is vital for a safer and more efficient system. Panaya’s RDx will give you all the information you need to manage changes to Salesforce picklists, workflows, formula fields, and custom objects as well as show you exactly what your changes have impacted.
Using Release Dynamix allows you to clearly understand these impacts, affording you visibility into what will break and where. RDx also enables you to better scope your development and testing process in order to ensure that you are properly focused on testing items that relate specifically to the project at hand.