We all want to be responsive to our stakeholders, including addressing requests and solving problems, but it’s critical that we understand the root cause and desired outcome behind the ask and only then match that information with the right Salesforce solution. This means not assuming the solution involves a certain feature just because they used words that reference specific Salesforce functionality.

Many words are easy to misconstrue when contemplating a business requirement, including approvals, notes, tasks, territories, and even leads. These terms all represent standard features in Salesforce, yet they can mean very different things once you dive into the use case.

There are usually multiple ways to solve a problem, each with many pros and cons. Even the Salesforce standard objects, available out of the box to support specific business processes, may or may not make sense based on the business requirements. It can be tempting to jump in and start solutioning. Still, it’s essential to understand the what and why before assuming the how. Armed with that information, you can apply your Salesforce knowledge and thoughtfully consider all the platform’s options.

Let’s look at an example. Your stakeholder says, “We need a place to put notes.”

Does this mean we should update our page layouts and add the standard Notes object? Maybe, but just because the words match some out-of-the-box thing in Salesforce doesn’t necessarily make it the right solution. After researching the desired business outcome, you may find that the solution warrants something else.

The Notes functionality can be an excellent tool for keeping users organized. It supports the addition of rich text, images, and formatted content. That’s good stuff, but when you drill into precisely what problem they’re trying to solve, you may find that they’re looking for a more confined, structured field on the detail page of a record. They may need to see those notes included in reports and list views for that object. So, the first order of business is to put on your BA hat and do a little digging to uncover the business objective.  

Pro tip: Whether it’s by phone or in person, make sure you have a live conversation. Emails and IMs are not the right mechanisms for these types of conversations. Keep in mind the goal is not to drill through a litany of pre-determined questions. It’s to have a few ready to start the conversation and then actively listen and consider what else you need to know.

 Talk Tracks: Sample Discovery Questions

• Tell me more about the notes you need to capture. What type of content would your team include? Can you provide examples?
• Who would be entering these notes, and under what circumstances?
• Who needs to see the notes? Any sensitivity with the contents that would preclude certain user groups from reading them?
• Is this a new process? If not, how is it being done today?
• Is a note required at a certain point in the process? If so, when?

• Will the content of the notes change over time? Do we need to retain a history of the prior version?
• What are the requirements for understanding who entered the note? Do we need to track when it was entered or last modified?
• Would plain text suffice, or is there a need to capture rich text or images?
• Talk to me about the size of the notes field. Do you have a sense of how many characters are needed?
• Where does that information need to be visible in the system?
• What are the reporting requirements?

Can you see how you might arrive at an entirely different conclusion depending on the answers? The solution you provide might be quite different depending on the information you uncover.  

Solution 1:

Perhaps they describe a scenario for which they need to capture a few sentences to add color to the Status field, maybe even requiring that users enter an explanation for a given status value. A text area field coupled with a validation rule is probably the right approach in this case, particularly if they need to include the notes in reports.

There’s no one-size-fits-all answer when determining Salesforce solutions. When a stakeholder tells you they need to “track their approval” for a certain business process, it may warrant creating a new approval process. Or, once you uncover what they are trying to accomplish, they may simply need a way to indicate on a record that they have reviewed the data. When someone asks you for assistance with forecasting, it may require activating the Collaborative Forecasting feature, or they may need help creating different types of pipeline reports.

Actively listening without taking the request at face value allows you to determine the best way to meet their objective, prevents re-work, and ensures you deliver the “right-sized” solution. Even when the ask sounds related to a specific feature, probing to understand the real need and then applying your platform knowledge will ensure you deliver the right solution every time.

To summarize, here are the 3 key takeaways you can implement in your next discovery session or when an enhancement request lands in your queue.

1. Do not jump to a conclusion on a solution as soon as you hear a keyword.
2. Probe to uncover the why behind the ask. Start with the 4Ws to get the conversation started: why do they need it, who will use it, what will they do with it, and where in their org does this relate? (Download a cheat sheet with talk tracks for discovery questions at www.sfadminbook.com)
3. Have a live conversation when discussing requirements. Email leaves too much room for misinterpretation.