A Solution Design Document (SDD) is the consolidated artefact that captures what the implementation will be — produced at the end of Discovery, signed off before Build begins.
Sections:
1. Executive Summary — problem, proposed solution, success metrics, in 1-2 pages for sponsors.
2. Stakeholders & Users — roles, responsibilities, expected user counts.
3. Current State — process maps, system landscape, pain points.
4. Future State — process maps, vision, user journeys.
5. Functional Requirements — what the system will do, by feature area.
6. Non-Functional Requirements — performance, security, compliance, scale.
7. Data Model — objects, fields, relationships. ERD.
8. Security Model — profiles, permission sets, sharing rules, OWD.
9. Automation — flows, validation rules, approval processes, triggers.
10. UI Design — Lightning Record Pages, page layouts, custom components, mobile considerations.
11. Integrations — systems to connect, integration patterns, data flows.
12. Data Migration — source systems, mapping rules, cleansing approach, sequence.
13. Reporting & Analytics — key reports, dashboards, KPIs.
14. Org Strategy — sandboxes, deployment approach, namespace.
15. Project Plan — phases, milestones, resource plan.
16. Risks & Assumptions — top risks with mitigation; assumptions that anchor the plan.
17. Out of Scope — explicit list of things NOT included. Critical for managing expectations.
18. Sign-off — who signs, what they're agreeing to.
Format: typically a 30-100 page Word doc, sometimes Confluence pages. Diagrams matter (data model ERD, integration flow, sharing model visualization).
Maintenance: SDD is living during Build but ideally stable. Major changes require formal updates. Sticking to one source of truth prevents "which version are we building?" confusion.
Senior consultant practice: write the SDD with the next consultant in mind — someone who joins the project mid-build needs to come up to speed from this document. If your SDD doesn't enable that, it's incomplete.