Functional design documents for Dynamics 365

A Functional Design Document (FDD) is the bridge between business requirements and technical configuration. Done well, it captures what the system needs to do for a specific business process, in language the business can read, and in detail the technical team can build. Done poorly, it's bloated, vague, or both — adding cost without yielding clarity.

The audience and purpose.

• Business stakeholders sign off on the design.
• Configuration team uses it as the build specification.
• Testers use it to derive test cases.
• Auditors use it as evidence of designed-and-approved process.
• Future maintainers read it to understand why things are as they are.

The FDD serves all of these — which is why one-size-fits-all templates struggle. Layered structure helps.

Per-process scope. An FDD covers one business process — "Customer Onboarding," "Vendor Invoice Processing," "Sales Order to Cash." Not the whole implementation. Discrete, focused FDDs are more useful than monolithic ones.

Standard sections.

1. Overview. One page:

• Process name.
• Purpose — what business outcome.
• In scope / out of scope.
• Stakeholders.
• Related processes.

This page sets context; readers continue or stop based on relevance.

2. As-is process. Current state:

• Steps in the existing process.
• Pain points being addressed.
• Volumes and frequencies.

For a greenfield implementation, "as-is" may be Excel spreadsheets and email; capture the reality.

3. To-be process. The designed future state:

• High-level flow narrative.
• Roles and responsibilities.
• Touchpoints with other processes.
• Key decisions / business rules.

4. Detailed flow. Step by step:

• Each step with role, action, system entity affected.
• Outcomes and exceptions per step.
• Screens / forms involved.
• Decision branches.

A swim-lane diagram or BPMN flow visualises this; the text describes the detail.

5. Business rules. Explicit rules:

• Validation rules.
• Calculation logic.
• Approval thresholds.
• Routing logic.

Numbered rules with examples; the test team derives test cases from this.

6. Data model. The entities involved:

• Which Dataverse tables or F&O entities.
• Custom columns to add.
• Relationships.
• Field-level requirements (mandatory, default values).

The data dictionary cross-references; the FDD describes the use.

7. Security model. Who can do what:

• Roles involved.
• Privileges required per role.
• Record-level access rules.
• Approval workflow ownership.

8. Integrations. Cross-system touch:

• Inbound — what flows in, when, format.
• Outbound — what flows out, when, format.
• Frequency and volume.
• Failure handling.

9. Reports and outputs. What the process produces:

• Reports — KPIs and lists.
• Documents — invoices, statements, contracts.
• Notifications — emails, in-app alerts.

10. Edge cases and exceptions. What goes wrong:

• High-value transactions.
• Cross-border / multi-currency.
• Disputes and corrections.
• Bulk operations.
• Concurrency conflicts.

Specifically called out so design doesn't ignore them.

11. Open questions / decisions pending. What's unresolved:

• Specific questions for stakeholders.
• Trade-offs to discuss.

Keeping these visible avoids decisions getting forgotten.

12. Decisions and rationale. What was decided and why:

• Specific choice made.
• Alternatives considered.
• Rationale.
• Decision maker and date.

This is the most-valuable-and-most-omitted section. Future maintainers benefit enormously from "why" history.

13. Test scenarios. Test cases derived from the design:

• Happy path.
• Edge cases.
• Failure modes.
• Performance scenarios.

The test team uses this directly.

14. Training implications. Who needs to learn what:

• Affected roles.
• New skills required.
• Training material types.

Specific gotchas to avoid.

• Vague language. "Should be flexible" — what does that mean operationally? Use specific, testable statements.
• Implementation details bleeding in. "Configure column X to Y" — that's TDD territory. FDD describes what, not how.
• Missing edge cases. Only happy path documented; production hits the edge cases on day one.
• No traceability. Requirements don't map to design sections; can't tell what's covered.
• No version control. FDD revised silently; team works from different versions.

Sign-off discipline. FDDs are signed off at the end of design phase:

• Business stakeholders sign for design correctness.
• Technical lead signs for feasibility.
• Project sponsor signs for scope alignment.

Sign-off doesn't mean "frozen forever" — changes happen — but changes after sign-off go through a change control process.

FDD vs requirements. Two layers:

• Business requirements document (BRD) — what the business needs at a high level.
• FDD — how the system fulfills those requirements.

BRD comes from the business; FDD is the analyst's translation into system terms.

Length. FDDs should be as long as needed but not longer. A typical process FDD is 10–30 pages. Anything beyond 50 pages is probably bloated or scoping multiple processes.

Format and tooling.

• Microsoft Word + SharePoint — common; reasonable for static FDDs.
• OneNote / Loop — better for collaborative live editing.
• Confluence — common in development-led organisations.
• Markdown — good for technical-leaning teams.

Choose what the team uses fluently; the format matters less than the content.

Common pitfalls.

• Documented after build. FDD reverse-engineered from configuration; lacks decision history.
• Boilerplate over substance. Lots of templated headers, little real content.
• No examples. Abstract rules; readers can't verify their interpretation.
• Visuals missing or stale. Diagrams that don't match the text.
• Ownership unclear. No one updates after go-live; document rots.

Operational rhythm. Drafts during design; review cycles with stakeholders; sign-off before build; updates during build for clarifications; final version at UAT. Post-go-live, document updates triggered by significant process changes.

Strategic positioning. A good FDD is a force multiplier: it shortens build time (clear specs), reduces defects (issues found during review), supports audit (signed-off design), accelerates onboarding (new team members read FDDs to understand the system). A bad FDD is wasted effort. Invest in fewer, better FDDs over many mediocre ones; train the team in writing them; treat them as living, accountable artefacts rather than tick-box deliverables.