# Business Central Functional Design Document Template

> Source: https://netray.co/tools/business-central-functional-design-document-template
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Document a Business Central customisation, report or integration with requirement, standard behaviour, gap, design, test and sign-off sections.

## Category

microsoft-dynamics

## Erp

Microsoft Dynamics 365 Business Central

## Audience

- BC functional consultant
- AL developer
- Business analyst

## Tool

**Kind:** template

**Output:** document

**Fields:**

#### FDD number

**Key:** fdd_id

**Type:** text

**Default:** FDD-014

#### Title

**Key:** title

**Type:** text

**Default:** Production order scrap reason code

#### Functional area

**Key:** area

**Type:** select

**Options:**

- Finance
- Sales
- Purchasing
- Inventory
- Warehouse
- Manufacturing
- Service
- Integration
- Reporting

**Default:** Manufacturing

#### Author

**Key:** author

**Type:** text

**Default:** A. Consultant

#### Date

**Key:** doc_date

**Type:** date

**Default:** 2026-11-09

#### Business requirement

**Key:** requirement

**Type:** textarea

**Default:** Operators must record a reason code whenever scrap is reported on a production order output line, so quality can analyse scrap by cause.

#### Standard behaviour

**Key:** standard

**Type:** textarea

**Default:** Standard BC records scrap quantity and scrap percent on routing lines but has no reason code on posted output journal lines.

#### Proposed solution

**Key:** solution

**Type:** textarea

**Default:** Add a Scrap Reason Code table and a field on the output journal line that is required when scrap quantity is greater than zero. Carry the value to the capacity ledger entry.

#### Priority

**Key:** priority

**Type:** select

**Options:**

- Must have
- Should have
- Nice to have

**Default:** Should have

#### Estimated effort (days)

**Key:** effort

**Type:** number

**Default:** 6

**Blocks:**

#### Functional Design Document {{fdd_id}}: {{title}}

**Body:** Area: {{area}}
Author: {{author}}
Date: {{doc_date}}
Priority: {{priority}}
Estimated effort: {{effort}} days

#### 1. Business requirement

**Body:** {{requirement}}

#### 2. Standard Business Central behaviour

**Body:** {{standard}}

#### 3. Gap and options

**Body:** Option A: configure standard functionality only.
Option B: personalise pages without code.
Option C: build an AL extension.

Recommended: see proposed solution below.

#### 4. Proposed solution

**Body:** {{solution}}

#### 5. Objects affected

**Table:**

**Columns:**

- Object type
- Name or ID
- Change
- Notes

**Rows:**

**0:** Table

**2:** New / extend

**0:** Page

**2:** New / extend

**0:** Codeunit

**2:** Event subscriber

**0:** Report

**2:** New / modify

**0:** Permission set

**2:** Add objects

#### 6. Data, migration and permissions

**Body:** Describe new setup data, migration of existing records and which roles need access. Include upgrade impact for future BC versions.

#### 7. Test cases

**Table:**

**Columns:**

- Test
- Steps
- Expected result
- Pass/Fail

**Rows:**

**0:** 1

**0:** 2

**0:** 3

#### Approvals

**Signatures:**

- Business owner
- Functional consultant
- Developer
- Project manager

**Notes:** Replace the placeholder rows with your real objects and tests. Object ranges must come from your assigned ID range in app.json. Check event availability in your BC version before committing to a design.

## Content

**Intro:** Every Business Central customisation should start with a short, shared document. This template walks from requirement to standard behaviour, gap, options, solution, objects and tests so consultant, developer and business owner agree before any AL is written.

**Sections:**

#### How to use it

**Body:** Fill the fields for one change at a time. State the requirement in business terms, not as a technical solution. Describe what standard BC does today, which is the evidence for the gap. Choose the proposed solution and estimate effort. Export the document, complete the objects and test tables, then collect sign-off from the business owner and the developer.

#### Configure, personalise or extend

**Body:** Business Central favours extensions over modifying base code. Always consider configuration first, then page personalisation or Power Platform options, and only then an AL extension. Extensions use events and extend existing objects, which keeps upgrades manageable. Documenting the options considered shows reviewers why code was needed and protects against scope creep.

**Bullets:**

- Prefer event subscribers over copying standard logic
- Keep each extension focused on one capability
- Record permission set changes in the same document

#### Writing good test cases

**Body:** Write tests the business can run in the sandbox: starting data, steps, expected result. Include a negative test, such as trying to post without the new required value, and a permission test with a limited user. Link the test IDs to your user acceptance test script so nothing built is left untested.

#### Common mistakes

**Body:** Skipping the standard behaviour section leads to rebuilding what BC already does. Another mistake is omitting upgrade impact: changes to posting routines, tables used by Microsoft apps and obsolete features cause trouble when BC releases a new wave. Finally, forgetting permission sets means a feature works for the developer and fails for every user.

**Cta:** Netray can accelerate specification and AL drafting with private AI assistants that stay under developer review. Ask how that would fit your partner team.

**Faq:**

#### Do I need a separate FDD for every change?

**Answer:** For anything beyond configuration, yes, but keep each short. One to three pages per capability is typical. Small related changes can share a document if they ship together and have the same owner and tests.

#### What is the difference between functional and technical design?

**Answer:** The functional design explains what the system should do and why, in business language. The technical design explains how objects, events and data structures will implement it. This template combines both at a light level; split them for larger solutions.

#### How do I estimate effort reliably?

**Answer:** Count affected objects, integration points, test effort and documentation. Add time for permissions, upgrade checks and review. Compare against similar past changes. Give a range when uncertainty is high and refine after the solution is validated in a sandbox.

#### Does the template cover Power Automate or API integrations?

**Answer:** Use the Integration functional area and list the endpoints, flows or web services in the objects table. Add authentication, error handling and volume notes in the data and permissions section, since those drive most integration defects.

## Search terms

business central functional design document template, dynamics 365 business central fdd template, business central fit gap template, business central customisation specification, al extension functional specification template, business central technical design document

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json