Running a Discovery Workshop

Why Discovery Determines Everything

In every Salesforce programme that encounters significant problems in build or UAT, there is a discovery phase somewhere in the history. In the good programmes, it's a rigorous 2-3 week phase that produced clear, agreed outputs. In the programmes that fail — or that arrive at go-live 6 months late and 40% over budget — the discovery was either rushed, incomplete, or produced documents that nobody actually used.

The commercial pressure against proper discovery is real. Clients want to see tangible output fast. Implementation partners bill for time and may benefit from scope changes that get discovered late. The instinct is to get to "build" quickly and figure things out as you go. This instinct is wrong, and the evidence for its wrongness is every Salesforce project that has ever said "we'll define the edge cases later" and then spent six months in UAT.

Discovery is not a phase you do before the real work starts. It is the real work — the work of understanding the problem well enough to build the right solution for it.

The Five Workstreams

A complete Salesforce discovery must address five distinct areas. Programmes that skip any of these will encounter the missing workstream as a late-stage problem — usually the worst kind.

1. Business Process Discovery

This is the workstream most people mean when they say "discovery." Mapping the current state process (AS-IS) and designing the future state process (TO-BE) for the business functions Salesforce will support. The key is to go deep enough to surface edge cases — the exceptions, the escalation paths, the seasonal variations — not just the happy path.

Process discovery must involve the people who do the work, not just their managers. The VP of Sales may describe the ideal sales process. The actual sales team knows the four workarounds they use every week that the ideal process doesn't account for.

2. Data Discovery

Data discovery answers three questions: What data exists today? What quality is it in? What needs to happen to it before it can live in Salesforce? The typical finding — in virtually every programme I have seen — is that the data is in worse condition than anyone believed, and the data migration work is larger than anyone budgeted.

Data discovery should produce a data model design (what objects and fields are needed), a data quality assessment (what percentage of records are fit for migration), and a data migration approach (will you migrate everything, or cleanse and migrate a subset?). All three should be agreed before Sprint 1 starts.

3. Integration Discovery

Every enterprise Salesforce implementation has integrations. Integration discovery maps every system that Salesforce needs to connect to: what data flows in which direction, at what frequency, in what volume, with what latency requirement. The integration landscape is almost always more complex than the initial scope suggested — systems appear during discovery that were not mentioned in the original business case.

Integration discovery should produce an Integration Architecture Map: every source/target system, data flows, direction, volume, and the integration pattern (real-time API, batch file, event-driven, etc.).

4. Technical Discovery

Technical discovery profiles the existing Salesforce environment (if one exists) and identifies the technical constraints that will affect build. For a new implementation on a greenfield org, this is lighter. For a programme building on an existing org, it is critical — existing automation, data volumes, integrations, and configuration all need to be understood before new development begins.

For programmes on existing orgs, technical discovery should include an Org Health Assessment: What automation already exists? What is the limit consumption profile? What technical debt has accumulated? What governance processes (or absence of them) have left the org in its current state?

5. Change and Adoption Discovery

Change management is consistently the most underinvested workstream in Salesforce programmes — and consistently the one whose absence causes the most visible post-go-live problems. Discovery should assess: How ready are the end users for this change? What is their current relationship with technology? What are the most significant pain points in the current process (which tells you what the new system needs to demonstrably fix)? Who are the natural change champions in each team?

The output of change discovery is a Change Readiness Assessment — a baseline understanding of organisational readiness that the training and change management plan is built on, rather than assumed.

Workshop Structure and Facilitation

A discovery workshop is not a series of meetings where a partner asks questions and takes notes. It is a facilitated process designed to surface decisions, not just collect information.

Who Should Be in the Room

For process discovery sessions: the people who do the work (not just their managers), a subject matter expert from the client side who understands the process deeply, a business analyst from the implementation partner who will translate process into Salesforce capability, and a solution architect who can flag implications in real time.

The Delivery Manager's role in discovery workshops is governance, not content. You are ensuring the right people are in the room, the session produces clear outputs, decisions are captured and owned, and the discovery stays on schedule. You should not be the one running the process workshops — that's the business analyst's role.

The Daily Structure

Each day of discovery should follow a consistent pattern: morning to define the scope of that day's exploration, mid-morning to surface the current state (AS-IS), afternoon to design the future state (TO-BE), and end-of-day to capture decisions made and questions that need answers before the next session.

The end-of-day decision log is critical. Every decision made in the room should be documented and agreed before people leave. "We'll come back to that" is the most dangerous phrase in discovery — it means the decision will be made under time pressure during build, when the business stakeholders have moved on to other priorities.

The Outputs That Actually Matter

At the end of discovery, a Salesforce programme should have produced specific, agreed artifacts — not just a comprehensive set of notes and a large slide deck.

Process Flows (TO-BE) — Documented future-state process flows for every process in scope, at a level of detail that an architect can design configuration from. "User enters account information" is not sufficient detail. "User creates Account record with Industry, Region, and Revenue fields; system auto-assigns to Sales team based on Region; system sends welcome email via Marketing Cloud" is.

Data Model Design — The agreed Salesforce object model: which standard objects will be used, which custom objects are required, the key fields on each object, and the relationships between objects. This does not need to be exhaustive (every field can be added during build) but the object structure and primary relationships should be agreed.

Integration Architecture Map — Every integration listed, with direction, pattern, volume, and frequency. Agreed by both the business and the technical teams.

Scope Agreement — What is in scope and what is explicitly out of scope for the first release. The out-of-scope list is as important as the in-scope list. Without it, every new requirement that emerges during build is a potential scope change dispute.

Risk Register — A documented list of identified risks with owners and mitigation plans. Discovery typically surfaces the most significant programme risks — data quality, integration complexity, change readiness, regulatory constraints. These should be formally recorded before build starts.

Architecture Decision Record — For any significant architectural choice made during discovery (org strategy, integration pattern, data migration approach), a brief record of the decision, the alternatives considered, and the rationale. This is the document that prevents "why did we do it this way?" questions six months into the programme.

Discovery Red Flags

These patterns in a discovery process reliably predict downstream programme problems:

Senior stakeholders only in the room. If the process discovery sessions only include managers and directors — not the actual users — the TO-BE process will be designed around the theory of how the work is done, not the reality.

Partner driving the TO-BE design. The implementation partner should facilitate and advise on what Salesforce can do. The client should design the future-state process. When the partner designs the process, the client doesn't own it — and will push back on it during UAT.

No data quality assessment before agreeing the migration scope. If the data migration plan is "migrate everything" without a sample data quality review, the programme will discover data quality problems in migration testing — which is a very expensive time to discover them.

Change management "to be addressed in a later phase." Change management that is deferred to a later phase is change management that doesn't happen. If it's not being planned in discovery, it won't be planned properly.

Discovery ending with significant open questions. If the discovery phase closes with more than a handful of genuinely minor open questions, the programme is not ready to start build. Starting build on an incomplete foundation is a choice — but it should be acknowledged as a risk, not disguised as a timeline achievement.