Custom Fields Best Practices in Salesforce | Critical Questions to Ask Before Making the Add скачать в хорошем качестве

Custom Fields Best Practices in Salesforce | Critical Questions to Ask Before Making the Add

A user sends over a request to add a new custom field to an object in Salesforce. On the surface, this may seem like a fairly routine task. We may not see a dire impact from it today, but over time, this lackadaisical approach will create a mess we’ll have to dig ourselves out of. Understand the Why First and foremost, we need to ask why we need this custom field. What is the business reason behind it? Essentially, what problem are we trying to solve? We need to dig into the business case and the process it supports. Without this, its easy to create clutter in our database and our user interface. Once you understand the why, it makes the rest of the questions in this list a lot easier. Are we already capturing this data? Next, is there already a field capturing this data. This may seem silly, but I’ve seen several occasions where a new field was requested that mirrored an existing one. Maybe the existing one was labeled something different, but the data capture was the same. When we add duplicates, it creates confusion for users and triggers a data management mess that we will pay for some time in the future. Never take a user’s word for it. Do the research yourself to ensure you aren’t duplicating efforts. This isn’t implying they are lying to you. Sometimes, they don’t realize it’s there. This is where having a data dictionary can be helpful to clarify the intent behind every field in a comprehensive view. Lastly, make sure this data doesn’t already exist on a parent object. We can easily pull that into the form via the formula field and display it as read-only text. What type of data are we capturing? This one goes hand in hand with our next question -- what type of data are we capturing? This answer helps us define the data type of the field and not fall into the trap of defaulting everything to a text field. If we understand it’s a number or a date, we can capture that appropriately and lean on Salesforce’s built-in tools to enforce data type checks. We also need to understand the nuances of our data. Do we need to capture rich text? How long is the dataset our users will be entering? If it’s a number, what precision do we need to capture from a decimal standpoint? Are there performance concerns if the need is for a formula field? Should this field be required? Our next question asks if this field should be required. We need to walk a fine line with required fields. If we get too strict, it impedes user progress and creates frustration to the point where they enter junk data to get around it. If we’re too lax, we fail to capture critical information necessary to run our business. Where should the field appear? We also want to ask where the field should appear on the form. If we shuffle fields at random, it can read like a ransom letter to our users. There are usually logical groupings in a form. How can we best group like items together so they make sense from a data entry perspective? Come to the table with suggestions for this one since you likely understand the flow of the existing form. How should we label our field? Next, how should we label our field and clearly relay its intention? We want to make our fields as self-explanatory as possible. Users shouldn’t be wracking their brains as to what a field is asking for. Use the help text to provide a succinct description of what the field is capturing. Without this guidance, people will bypass the field or add junk data to minimize their confusion. What is the impact of this change? We also need to ask, what is the impact of this change? Are there reports and dashboards that will need to be updated to display this data? Do we need to pass this field through existing APIs and integrations to keep it in sync with external systems? Will it have dependencies on other fields? A data ecosystem is a tangled web. We need to make sure we account for these various threads so we don’t miss a critical step. How does security factor in? I hope you didn’t forget about security. Who should have access to this field and how are we opening this up from a Profile, Permission Set, and Role Hierarchy perspective? Are we making the field visible for certain users and not others? Are we capturing sensitive or confidential information? Take time to understand the security needs of this field addition. How do we get this into production? Lastly, don’t forget the last mile. How are we getting this change into production? What is the timeline for getting this released? What does testing look like from a sandbox and UAT perspective? Who needs to sign off on that testing before it is pushed to production? What documentation needs to be updated to reflect this change? Videos Courtesy of Freepik