# How to run Salesforce discovery from the org, not just the interviews. > Running Salesforce client discovery with SyncOnAI 360 means connecting the client's org, reading its health, audit and architecture profile, asking it questions in plain English, recording discovery calls as transcripts beside the org, and turning what you find into evidenced findings that feed the proposal. Source: https://synconai360.com/use-cases/client-discovery ## Key facts - **55**: Audit checks on the client's org - **1**: Workspace for evidence and interviews - **Every**: Finding with its evidence - **0**: Records copied out of the client's org ## Why Salesforce discovery takes too long and misses things Discovery is weeks of workshops and screen shares. The client describes the org as they remember it, and the surprises appear in the build phase. - **Memory, not evidence.** Stakeholders describe intended behaviour, not actual configuration. - **Weeks of workshops.** Discovery time is hard to bill and easy to overrun. - **Surprises later.** Hidden automation and debt appear mid-build. - **Notes everywhere.** Interview notes and org findings never meet. ## How do you see a client's org during discovery? Have the client connect the org, or a recent sandbox, with Salesforce OAuth. It syncs in the background with progress shown; metadata and source are read, CRM records are not. Health, the audit and the dependency graph follow from the same sync. - OAuth connection - Metadata, not records - Health and audit from the sync ## What should you read first? The health score and the audit's weakest sections, the Architecture lens for how the org is built, and the automation on the objects the project will touch. Ask the chat to explain the processes stakeholders describe, and compare. - Weakest sections first - How the org is built - Stated versus actual ## How do interviews and evidence come together? Record discovery calls in a browser tab and the transcripts are saved as pages in the same workspace as the org. Ask the chat to pull out the requirements, and check them against what the org actually contains. - Calls transcribed into pages - Requirements extracted - Checked against the org ## How do you surface risks before the build? Lineage shows what depends on the components the project will change, and the audit lists overlapping automation, legacy rules and security exposure with evidence. Risks found now are priced into the proposal, not discovered mid-build. - Dependencies of the change area - Evidenced risks - Priced into the proposal ## What does discovery produce? Evidenced findings with effort and cost, transcripts and requirements as pages, and a read-only audit report the client can open. Selected findings become a priced statement of work in one step. - Evidenced findings - Requirements as pages - A statement of work ## Which questions should discovery answer from the org? What runs on the objects the project will change, which automation overlaps, how security is set up, which packages are installed and how much of the code is tested. Each of these is answered from the synced org rather than from memory. Ask the stakeholders why things were built; ask the org what was built. The gaps between the two are where the project risks are. - Automation on key objects - Security and packages - Test coverage ## How to run discovery 1. **Connect.** The client connects their org or a sandbox. 2. **Read.** Health, audit and architecture first. 3. **Interview.** Record calls as transcripts. 4. **Compare.** Check stated behaviour against the org. 5. **Report.** Share findings and price the work. ## Discovery, from memory versus from the org | Without | With SyncOnAI 360 | |---|---| | Stakeholders' memories | The org's actual configuration | | Weeks of workshops | An audit within the first session | | Surprises mid-build | Risks priced up front | | Notes apart from evidence | Transcripts beside the org | ## Discovery checklist - [ ] Get the client to connect the org or a recent sandbox. - [ ] Read health, the audit and the architecture profile before the first workshop. - [ ] List the objects and processes in scope and ask what runs on each. - [ ] Record workshops as transcripts beside the org. - [ ] Compare what stakeholders describe with what the org contains. - [ ] Note risks with their evidence and cost. - [ ] Share a read-only audit and turn findings into a statement of work. ## Who runs discovery - **Consultancies.** Shorten discovery and start the build from evidence. - **Independent consultants.** Run professional discovery without a team. - **Solution architects.** Base the design on the org as it is. ## Frequently asked questions ### Does the client have to connect production? No. A recent sandbox works for most discovery. ### Are the client's records copied? No. Metadata is read; CRM records are not stored. ### Can discovery calls be transcribed? Yes, from a browser tab, saved as pages. It needs an OpenAI key for now. ### Can the client see the findings? Yes, as a read-only audit report link. ### Can findings become a proposal? Yes. Selected findings become a priced statement of work in one step. ### How long does the first sync take? Several minutes for a large org, in the background. ### Can discovery feed an engagement? Yes. Engagements carry the statement of work into the deal room. ### Is this on every plan? Yes. Every plan includes every feature. ### Can we compare what stakeholders say with the org? Yes. Ask the chat to explain a process and compare it with the interview transcript. ### Do we need the client's admin? Only to authorise the connection and, later, to approve changes. ### How much does discovery cost the client? That is your pricing. The audit gives you evidence and estimates to price discovery findings consistently.