As a Salesforce consultant, we have all been there...
The business users asks for a checkbox field on the Account record. You think, this sounds simple enough and you create the checkbox.
Two weeks later they come back and need to know the date this checkbox was checked and need to be able to report on it easily. You create the date field and an automation that will update the date when the checkbox checked.
A week later, they decide they need a dropdown to track the status of the checkbox and they want the new status field to be required when the checkbox is checked. You create a picklist field and a validation rule.
A month later, they ask for a way to track more than one date because what they are tracking can happen more than once. You put your hand on your head, knowing this change will require a custom object related to the Account and you will have to migrate the existing data. Everything you have built - three fields, validation rule and automation - is now trash.
This progression of requests has caused a lot of wasted time and money, because the process changed three times. Business users had to be trained three times, multiple meetings to gather new requirements, documentation had to be updated three times and a complete rebuild on how the data was stored in Salesforce. Now, your first reaction may be frustration with your business users. But, whose fault is it really?
When the business asked for a new checkbox field, what questions did you ask? Did you only ask for field name and type? If your answer is "I did not ask anything", then it is your fault. It is not the business user's responsibility to know what to build in Salesforce to solve their problems.
The most important question for you to ask
What problem are you trying to solve? You need to build what the business needs, which is not necessarily what they ask for. YOU are the Salesforce expert, it's your job to make sure what is built in Salesforce is correct. Not just for today but for the long term. Scalability is one of the most important needs in Salesforce architecture. Will the new development fit their needs for today or will it last for many months to come?
The most important part of your job is to LISTEN and UNDERSTAND the business need at it's core. Not take orders, no matter how small the request is.
Example questions to ask when you are asked for a new field
- What is the business problem you are trying to solve?
- What will this field be used for?
- How or who will update it?
- How often will it be updated?
- Can this event or process happen more than once?
- What are other things that would be helpful to track around this process?
- Do you need to report on it?
- Is this field required? If yes, under what conditions?
Now, maybe you didn't ask any questions because you've had too much push back when implementing custom objects in the past. All you can do is arm yourself with information and communicate what you know to the business.
Be ready to offer solutions when you hear push back to help 'sell' your ideas
Here are the common objections to implementing a custom object:
- It is too hard to enter the data: You have an arsenal of tools in Salesforce to make things easier on users - screen flows and custom actions are two things that will help a user enter data quickly and correctly.
- Need to see or report from data directly on the Account record: App Exchange packages like Declarative Roll Up Summaries can help you roll up data at the parent object level.
Be ready to explain
Be ready to explain why creating checkbox 1, date 1, checkbox 2, date 2 is not the right way to store data vs a custom object:
- Field limits: storing data like this on an object will cause you to hit your field limit on an object very quickly
- Reporting is difficult: the data has to be shown in columns versus rows on a report, not ideal for many reasons
- Harder to see data on Account record: a custom object will allow you to see the data in rows and sort by a column
Are you mocking this up in a sandbox environment and showing them how it will look? This is important as well. Most of us are visual people and we need to see a solution before we really understand it.
Sometimes, you will not win the battle and that is ok too. The business user may say "Just create the field, we don't have time to think about this right now." Have the courage to say "This is not the right thing to do and you don't agree with it... but I will create it for you." If the business does not have time to think about what they need built, then they are not ready for the new field.
Other times, you may get a request from someone who has been using Salesforce for 10+ years and you may think they must know exactly what they need and have thought it through completely. They haven't been developing on Salesforce for 10+ years, only using Salesforce for 10+ years, there is a big difference here. It is your job to make sure what they are asking for is truly what they need. You are the expert, remember that.
You may also encounter some business users who feel intimated by your long list of questioning. They may feel inadequate because they do not know the answers to your questions. I have learned to preface my line of questioning with "I am going to ask you a series of questions and I do not expect you to have all of the answers or make decisions right here on the spot. The purpose of these questions is to make sure I understand what you need and what we build in Salesforce is correct."
A true consultant is someone who
A true consultant is someone who guides the requestor through the request and thought process by asking thought provoking questions. Don't be afraid to ask questions and tons of them!
I have heard people tell me, "I thought I knew what we needed until you started asking me these questions". If you hear this, it means your questions are making them think through the process and this is a great thing! I have also had people say "No, not Cheryl!" when they see me on call because I ask so many questions that really make them think. Don't be afraid to be this person, you will ultimately help them more than you will ever know.