Salesforce discovery readiness: what your team should prepare before kickoff

Most failed or delayed Salesforce programs do not collapse because of bad code on day one. They struggle because discovery answers were fuzzy: nobody agreed on what “done” meant, which systems were in scope, or which workflows actually ran the business. If you are weeks away from a discovery workshop with a consulting partner, use the preparation below to shorten cycles, reduce rework, and give your partner enough signal to design the right architecture.

Clarify the business outcome first

Write one paragraph that answers: What will be measurably better for customers or employees six months after launch? Revenue, cycle time, compliance posture, and ticket volume are all valid anchors. Avoid listing twenty goals; pick two primary outcomes and two secondary. Your partner will map capabilities to those outcomes instead of boiling the ocean.

Inventory systems that touch the customer record

Create a simple table: system name, owner team, read/write role relative to customer or order data, and refresh frequency. Include spreadsheets, legacy databases, and SaaS tools—not only “official” integrations. Gaps here are where surprise middleware and manual CSV bridges appear late in the project.

Bring real examples, not ideals

Collect three to five anonymized scenarios that span your exceptions: multi-region pricing, partner resale, government reporting, or field service edge cases. Narratives beat abstract requirements because they expose sequencing rules and approval chains that never made it into a BRD.

Assign decision rights before the room fills up

Discovery stalls when every question routes to a committee. Name a product owner who can commit on behalf of sales, service, and operations for day-to-day scope questions, and reserve executive sponsorship for policy trade-offs (for example, data retention versus UX friction).

Define minimum viable reporting

List the dashboards or KPIs that leadership checks weekly today—even if they are ugly. Replacing them is easier than inventing net-new analytics under delivery pressure. Note which metrics are sourced outside Salesforce so integration priorities stay honest.

Security and compliance checkpoints

Summarize current identity practices (SSO, MFA), regulated data classes you store, and any audit windows in the next twelve months. Your partner can align with security review expectations early instead of retrofitting controls after configuration hardens.

What good looks like at kickoff

You should arrive with shared vocabulary, bounded scope hypotheses, and visible pain in the form of examples—not a perfect specification. The goal of discovery is informed design, not exhaustive documentation frozen in amber. If your materials hit the themes above, your team will spend less time chasing context and more time shaping a solution that survives contact with production.

Field readiness for admins and power users

Export a current field-level security matrix for the objects you know will change. Highlight fields that are manually maintained today versus calculated or integrated. Partners use this to estimate data quality workstreams and to avoid “surprise mandatory fields” that break integrations during UAT.

Change impact on downstream teams

List teams that consume Salesforce exports, nightly jobs, or analytics cubes. Discovery should capture their refresh windows and failure handling. A warehouse that assumes nightly Account updates will break silently if your new validation rules block partial updates.

Technical debt you already know about

Document workarounds: unmanaged packages nobody wants to touch, Apex classes that run “hot” during month-end, and profiles that grew organically. Your partner will not judge you for debt—they need visibility to avoid stacking new features on unstable foundations.

Workshop logistics that save hours

Send pre-reads with the scenarios and tables above at least three business days early. Limit live workshops to decision-making time; circulate read-only material asynchronously. Time in discovery is expensive; spend synchronous hours on trade-offs, not on reading slides aloud.

When discovery ends, you should have a prioritized backlog, a draft target architecture, and a shared risk register. That package is what lets implementation start with momentum instead of with another discovery disguised as sprint zero.