Salesforce discovery: build a reliable understanding of reality

Salesforce project discovery should leave a team with a reliable understanding of the business situation: why the project exists, how work happens today, and which questions still need answers before design can proceed.

That is different from collecting a list of requested features. “Automate the handoff” records something a stakeholder wants. It does not yet explain what is going wrong, what a successful handoff means, or which conditions the automation must respect.

Understand why the project exists and how things work today

Start by understanding why the customer is reaching out. What do they want to achieve through this project, and why does it need to happen now?

They may want to support a growing team, improve customer service, or make day-to-day work easier. Before discussing individual features, get a clear picture of the overall goal:

• What should this project change for the business?

• Why is that change needed now?

• What would a successful result look like?

The aim is to explain the mission in plain language: why the project matters and what the customer wants to be different when it is complete.

Map the process as it happens today

The current process is more than the sequence shown in a diagram. It includes the people, systems, decisions, and exceptions that make the sequence work.

Follow a real example from beginning to end:

• Who starts the work, and what information do they have?

• What tells the next person that something is ready?

• Where does information move between Salesforce, email, spreadsheets, and other systems?

• Who checks whether the handoff is complete?

• What happens when information is missing or the normal sequence does not apply?

Work outside Salesforce matters. A spreadsheet used to reserve delivery capacity may explain why an opportunity stage alone is not enough to trigger the next step. Record the relevant tool stack and what each system contributes, including where information is copied or a handoff depends on another team.

Distinguish the people doing the work from those accountable for the process and those authorized to make decisions. Their perspectives can all be relevant without being interchangeable. A process owner may describe the intended workflow; a delivery coordinator may show the workaround that keeps it moving.

Record the starting point as well: current delays, errors, manual effort, or missed handoffs that explain the business impact. Preserve the source, period, and definition of each measure. Where reliable baseline data is missing, mark that gap and decide how to establish it.

Capture constraints alongside the process. Existing integrations, unreliable data, access restrictions, deadlines, budget, and organizational boundaries can change which solutions are feasible. A constraint discovered late can invalidate a design that looked reasonable in a workshop.

Gather information from people, processes, and Salesforce

Interviews explain goals and interpretations. Workshops let people from different teams compare their accounts and resolve questions together. Walkthroughs show what happens in particular cases. Existing documents preserve earlier decisions. Salesforce analysis helps establish what the system currently permits and does.

Review relevant meeting transcripts, process documents, spreadsheets, tickets, and previous decisions alongside what people say today. Check their dates and status so an old decision does not quietly become the current rule.

Keep the investigation connected to a business question. Salesforce’s customer-centric discovery guidance emphasizes understanding customers’ business challenges and objectives. When reviewing the org, focus on the configuration and data that affect the process being studied.

For a sales-to-delivery handoff, examine whether the information Delivery needs is available when Sales considers the deal complete. Check the relevant fields, who can view or edit them, which automation runs, and what the integrations pass to other systems. Record what the system actually does, including the conditions under which it behaves differently.

For each important observation or statement, keep enough evidence for someone else to understand where it came from:

• A stakeholder’s account: who explained the rule or process, when, and in what context.

• An observed example: which case was reviewed, what happened, and any relevant conditions.

• An existing document: its source, date, and whether it is still current.

• A system finding: the relevant configuration, data, or test result that supports it.

Label explanations that have not yet been checked as assumptions. For example, seeing a handoff succeed in two cases does not establish that it works the same way in every case.

Check these notes with the people who supplied the information or demonstrated the process, so their statements and examples are captured accurately. The resulting evidence gives the team a basis for investigating the gaps and contradictions addressed in the next section.

Resolve contradictions and make grey areas explicit

Make ambiguous terms concrete

People can agree on a label while disagreeing about what it means.

In a hypothetical Salesforce project, Sales, Delivery, and Finance might each attach a different condition to “Closed Won”:

• Sales
  The commercial agreement is complete
  What evidence establishes that?

• Delivery
  Work is ready to be planned
  Are scope and capacity confirmed?

• Finance
  The transaction is ready for billing
  Which billing conditions must be met?

These interpretations do not automatically mean one team is wrong. They may describe separate milestones that have been compressed into one term.

Discovery should establish whether capacity reservation, project creation, and invoicing belong to the same event or require different conditions. Otherwise, automating a shared label can hide an unresolved business decision.

Ask for the condition behind the term: “What must be true before this action happens?” That answer is more useful for solution design and testing than the label alone.

Reconcile information into a reliable source of truth

What people request or describe is not always clear, consistent, or correct. Someone may leave out an important condition, describe an outdated process, or present an assumption as a fact. Discovery means comparing what you have gathered and checking what can be relied on, rather than simply recording everything you hear.

Bring together the interviews, process walkthroughs, documents, and findings from the org. Look for gaps and contradictions. If two accounts disagree, go back to the stakeholders who perform the work, own the process, or have authority to decide the rule. Ask them to explain the difference and review concrete examples together.

For example, in a hypothetical project, Sales says every Closed Won opportunity creates a delivery project automatically. Delivery says projects are created manually after scope approval. Reviewing recent records and the relevant automation with both teams can establish whether one account is outdated, whether there are exceptions, or whether they are describing different steps.

Separate what happens today from what people want to happen. An existing automation shows how the system behaves; it does not prove that the behavior matches the business need. If the future rule is still disputed, the appropriate decision-maker needs to resolve it.

Keep the information that has been checked, correct what is inaccurate, and make terms, conditions, and exceptions explicit. Record where each important conclusion came from and who confirmed or decided it. Anything still unresolved should remain clearly marked rather than quietly becoming a requirement.

Separate conflicting requirements, missing information, outdated documents, and legitimate exceptions. For each significant uncertainty, state the question, its effect on the design, and who will investigate or decide it. Make clear which decisions must wait and which work can continue. Record the answer, who approved it, why it was chosen, and which requirements or process steps it changes.

The aim is a shared source of truth that stakeholders recognize and the implementation team can rely on.