A Salesforce discovery workshop should do more than collect a list of fields, dashboards, and automation requests. It should help everyone understand what the business is trying to improve, where current processes are breaking down, and what Salesforce needs to support before anyone starts building.

Skipping this work can make an implementation feel faster at first. However, it often leads to unclear requirements, unnecessary customization, scope changes, and a system that does not reflect how teams actually work.

Here is what a productive discovery workshop should accomplish.

Start With the Business Problem

Discovery should begin with the reason behind the project.

The organization may want better pipeline visibility, more reliable forecasts, faster lead follow-up, stronger handoffs, or less manual work. Those outcomes should be clear before the conversation shifts to Salesforce features.

Salesforce’s implementation guide recommends identifying the organization’s vision, pain points, goals, and priorities before setup begins. That context helps the team decide which requirements are essential and which requests can wait.

Otherwise, discovery can quickly become a wish list. Every request may sound useful on its own, but together they may create a complicated system without solving the original problem.

Map How Work Happens Today

A Salesforce discovery workshop needs to capture the real process—not just the process described in a document.

For example, the official sales process may require representatives to update opportunities every week. In practice, some may keep notes elsewhere and enter information only before a forecast call. Marketing and sales may use different definitions of a qualified lead. Customer success may receive incomplete information after a deal closes.

These gaps are important because they affect the way Salesforce should be configured.

The team should walk through the customer lifecycle from the first interaction through qualification, sales, onboarding, renewal, and expansion. For each stage, clarify:

• Who owns the work?
• What information is required?
• Which systems are involved?
• Where do delays or errors happen?
• What does the next team need for a successful handoff?

The goal is not to copy every existing process into Salesforce. It is to determine which processes work, which need to change, and which should be eliminated.

Revenue Ops’ guide to aligning Salesforce with the sales process explains why the platform must reflect how a team genuinely sells. When Salesforce does not match reality, users usually create workarounds.

Include the People Doing the Work

Leadership can explain what the business needs to achieve. Frontline users can explain what makes that difficult today.

Depending on the project, discovery may include representatives from sales, marketing, customer success, finance, operations, IT, and data teams. Not everyone needs to attend every session, but every affected group should have a voice.

Daily Salesforce users can identify details that leadership may not see. They know which fields are confusing, which approvals slow down deals, and which tasks are being completed in spreadsheets because the CRM process is too difficult.

At the same time, someone must have authority to make decisions. Discovery can stall when every stakeholder has input but no one owns final approval. The team should identify who will approve requirements, process changes, and scope before the build begins.

Review the Data Early

Many Salesforce projects run into trouble because data is discussed too late.

Discovery should identify where prospect and customer data currently lives, how it enters the business, which system owns each record, and whether the information is reliable enough to migrate or automate.

Common problems include duplicate accounts, incomplete contact records, inconsistent lifecycle stages, outdated picklist values, and unclear ownership. These issues should be understood before the team designs routing rules, reports, lead scoring, or AI-powered workflows.

The same principle applies when evaluating Data 360 (formerly Data Cloud). Connecting data from multiple sources can create a more complete customer view, but the team still needs clear data sources, identity rules, permissions, and use cases.

Automation cannot correct a process that no one has defined. It can only repeat that process faster.

Understand the Entire Technology Stack

Salesforce rarely works alone. A discovery workshop should review the systems connected to marketing, sales, service, finance, and customer success.

For each integration, the team needs to understand what data moves between platforms, how often it syncs, which system is the source of truth, and what happens when the connection fails.

This conversation often reveals that the real problem is not missing Salesforce functionality. It may be duplicate processes, conflicting records, or unclear ownership across systems.

Creating a simple system map can make those dependencies easier to see. Salesforce’s architecture reference diagrams offer useful examples for visualizing systems, capabilities, integrations, and data flows.

Separate the Need From the Requested Solution

Stakeholders often arrive with a specific solution in mind.

• “We need another approval flow.”
• “We need a custom object.”
• “We need a new dashboard.”
• “We need AI.”

Those requests should be captured, but discovery needs to uncover the problem behind them. A request for an approval flow may indicate inconsistent discounting. A dashboard request may point to unreliable opportunity data. An AI request may come from sales representatives spending too much time on repetitive research or follow-up.

Once the underlying need is clear, the implementation team can recommend the simplest solution that will work over time. That solution may involve Salesforce configuration, but it could also require better data, a process change, user training, or a clearer governance model.

This helps prevent the overbuilding that often makes Salesforce harder to use and maintain. As Revenue Ops explains in its article on common CRM optimization mistakes, adding more fields and automation does not automatically create a better CRM.

Define Priorities and Success Measures

A discovery workshop should end with clear documentation, not a collection of scattered notes.

The final output should summarize business goals, current processes, pain points, requirements, data sources, integrations, risks, dependencies, and decision owners. It should also separate immediate requirements from future improvements.

Not every request belongs in the first phase. Priorities should be based on business value, urgency, user impact, complexity, and technical dependencies.

The team should also agree on how success will be measured. Useful measures may include better data completeness, faster lead response, increased user adoption, improved conversion rates, more accurate forecasts, or less manual work.

Build From a Shared Blueprint

The goal of a Salesforce discovery workshop is not to delay the implementation. It is to make sure the team builds the right system.

When business processes, data needs, technology dependencies, and success measures are clear, the build becomes more focused. Scope is easier to manage, technical decisions have a purpose, and users are more likely to receive a system that supports their daily work.

A strong discovery workshop creates the blueprint for everything that follows. Without that blueprint, even a technically successful Salesforce implementation can solve the wrong problem.