Introduction
Design exists to turn the Functional design document into a reviewed set of approved parts: the gaps, an agreed approach, the personas, functional and technical designs, training material, tests and a test data plan. Its governing gate is Designs Approved and Tests Frozen. The frozen tests are the contract the build must satisfy, not a description rewritten to fit whatever the code happens to do. This article explains the steps in this stage in detail, what freezing the designs and tests means, and the gate that must be satisfied before any code is generated.
The stage produces the work that a consultant would otherwise write by hand and your job as the end user will ultimately be to review it and decide whether it is correct.
Design will turn the design document into a reviewed solution. Completed Compass steps are navigation signals, not a substitute for reading the artifacts and approval record. If you inherit a project whose steps are already checked, establish what was reviewed and by whom before treating that approving that history.
Before you start
Have the design document and relevant attachments available, understand the target Business Central sandbox and installed apps, and agree who will review the business scope and technical approach. Check that acceptance criteria describe the relevant outcomes and that the intended users and permissions are understood.
Confirm the project template which applies to your project first.
The nine steps
The Compass order is Gaps, Solutioning, Personas, FDDs, Training, TDDs, Test Cases, Freeze and Data Plan. Training therefore appears between the functional and technical designs in this project.
Gaps
The goal is to analyse the design document against standard Business Central and the apps already installed, carrying forward unmet requirements rather than rebuilding available functionality. Review each gap against the original requirement and the actual environment. Distinguish a configuration or process change from something needing an extension, and challenge a proposed gap when an installed capability already addresses it.
Check that the business impact and acceptance criteria are clear enough to support a decision. Record corrections in Consultant Notes so they inform the next regeneration. Gaps can be excluded from scope, but review the resulting scope deliberately: exclusion is not evidence that the underlying business need has been solved. The outcome is a defensible gap set with an explicit disposition for each requirement.
Solutioning
Review how each gap should be handled, including whether an existing capability should be reused or procured instead of built. Useful review dispositions include build, defer, reject, do manually or use existing IP; these are decision guidance, not a promise of the exact labels in every interface. Make the rationale clear enough for another reviewer to understand the chosen scope and any residual limitation.
Solutioning produces Business Solution Architecture and Technical Solution Architecture documents alongside the per-gap designs. These architecture documents replace the earlier combined or gap-zero documents, not the individual FDDs and TDDs. Read the overall approach as well as each gap decision: check that dependencies, shared processes and the procure-versus-build choice form one coherent solution. The outcome is an agreed approach, not simply a populated document list.
Personas
Confirm the proposed personas against the people who will operate, supervise and support the process. A persona should identify a meaningful role and its tasks, not merely a job title. Check normal responsibilities, approvals, exceptions and separation of duties. Ask what each role must be prevented from doing, as well as what it must be able to do.
The outcome is a confirmed role model that the designs, training and tests can use consistently. Trace important requirements to the affected personas and look for missing users at hand-offs. Negative permission scenarios belong in the review: a role without authority should not gain access simply because the happy-path process works.
FDDs
Functional Design Documents describe what the solution must do from the business user’s perspective. Review the included documents against the agreed gap dispositions, architecture and personas. Follow the process from input to result, including validations, exceptions, approvals and recovery from mistakes. Check whether a business reviewer could recognise a correct outcome without needing to inspect implementation code.
Acceptance criteria should be unambiguous and testable. Review success, failure and boundary conditions, and check that role restrictions are explicit where they matter. Use Consultant Notes to record corrections for the next regeneration. FDDs can be excluded from scope, but do not assume that exclusion automatically satisfies the FDD step or leaves every dependent artefact unchanged; verify the scope and ask when the project history is unclear.
The outcome is a functional baseline the business reviewers can stand behind. Generated content is not itself approval, and a checked Compass step does not explain the review that preceded it. Retain the relevant version and approval evidence rather than inferring completion from the presence of an FDD.
Training
Review the training material for the confirmed personas and functional process. Check that it explains prerequisites, routine tasks, likely errors and escalation points in language the intended user understands. A training document should not introduce a different workflow, promise access the persona lacks or describe an excluded feature as available.
Consultant Notes on training inform its next regeneration. The outcome is training aligned with the agreed solution, ready to be checked against the eventual sandbox behaviour. At Design, do not describe training as proof that the feature has been implemented or that users have completed training.
TDDs
Technical Design Documents describe how the agreed functional behaviour is intended to be implemented. Have a suitably experienced Business Central technical reviewer assess the approach; this is review advice, not a claim about enforced product permissions. Check consistency with the FDDs, installed apps and Technical Solution Architecture, including dependencies, data handling, permissions and error handling. Technical detail should resolve the functional intent, not quietly change it.
In Technical Designs, inspect the current rows and use Download to read the relevant documents. The recorded list shows Gap No., Type, Version No., Status, Source, Confidence, Ass. Flag and Freshness. It includes TDD and technical architecture entries. Treat these columns as review information; a confidence or freshness value does not replace checking the document and its relationship to the approved scope.
Visible actions include Approve, Re-include Design, Exclude Design, Show All, Approve All Reviewed and Needs Review. Do not infer the selection rules or effect of the bulk actions from their names alone. TDDs can be excluded and Consultant Notes inform their next regeneration. The outcome is a technically reviewed baseline with any scope changes made explicit, rather than an assumption that every Approved row proves the whole Design gate.
Test Cases
Test cases are derived from the designs and acceptance criteria before code is built. Review whether each important criterion has meaningful coverage, with suitable personas and observable expected outcomes. Include invalid input, boundary conditions, denied permissions and recovery scenarios where the requirements call for them. Coverage is not convincing if every case repeats the same successful route while leaving exceptions untested.
Use Test Cases from the Test Suite card to inspect the suite. Check the meaning and resolution of any draft or rejected cases rather than overlooking them because other cases are frozen. The outcome is a reviewed set of cases tied to the intended behaviour, with outstanding review decisions addressed before sealing the contract.
Freeze
Freezing protects the agreed baseline. Frozen tests must never be regenerated or weakened merely to make failing code pass. If a test exposes an implementation defect, correct the build. If the business requirement genuinely changes, treat it as an authorised design change with recorded rationale and review, not a shortcut to a green result.
Before treating a suite as ready to freeze, check the included scope and design versions, functional and technical review evidence, persona and permission coverage, traceability to acceptance criteria, outstanding case verdicts and any justified omissions. Confirm that reviewers understand what the expected outcomes commit the build to delivering. This is a review checklist, not a claim that these are the product’s exact enforced prerequisites.
For an existing suite, inspect the state, Suite Frozen At and the statistics: Total Cases, Frozen, Drafts Awaiting Verdict, Rejected and Criteria Coverage. The recorded card states “FROZEN – the suite is the sealed contract”. Freeze Suite is disabled while frozen; Unfreeze Suite, Test Cases and Test Data Plan are visible. The recorded example had all cases frozen and full criteria coverage, but it does not establish universal thresholds.
Read Freeze History alongside the current state. Its visible columns are Event, At, By, Criteria Covered, Total Criteria, Cases Frozen, Cases Rejected and Reason. This helps distinguish the present suite from the event that sealed it. In the recorded Express project, the history reason begins “Auto-frozen by the EXPRESS PHASE chain…”. An automatic freeze event is not, on its own, evidence of human review; confirm the approval record appropriate to the template.
If a genuine design change requires unfreezing, establish the authorised change review and record the reason first. Clicking Unfreeze Suite with an empty Reason box produced: “Unfreezing is a recorded design-change event – write the reason in the Reason box first.” No successful unfreeze is shown. Do not assume its consequences for approvals, tests or Build, or a re-freeze sequence, until those rules are confirmed.
Data Plan
Review the test data plan against the source cases and frozen contract. Check the seed and transactional data needed to exercise the process, including dependencies, roles, record quantities and values needed for negative and boundary scenarios. Ensure the proposed data can be prepared safely in the sandbox and that test execution will not depend on unstated manual setup.
The Test Data Plan card shows Approve Plan and Consultant Notes, with Project No., Status, Generated At, Source Cases, Approved At, Approved By and Notes. The recorded plan is Approved. Its Entities list shows Name, Kind, Persona, Records Needed and Table. Review these together for sufficiency and consistency; do not assume that an approval label proves the data is already present.
New Line and Delete Line are visible, but treat entity changes as changes to the preparation plan, not casual housekeeping. The outcome is a reviewed plan that supports repeatable test execution. The precise generation, approval and Design-completion rules need confirmation for the template in use.
Before moving to Build, make sure the designs describe what the end user needs and the tests cover the agreed acceptance criteria. ARVO prepares the documents; you still need to review them and complete the approvals required for your project.
Check that:
- The gaps and included scope are correct. If you chose to build something instead of using an existing capability, record why.
- The personas reflect the people who will use the solution.
- The functional and technical designs are the versions you reviewed, and any corrections are included.
- The training documents match the agreed solution.
- The test cases cover the requirements, and the test data plan includes what is needed to run them.
If you added Consultant Notes, check the regenerated document before approving it. Adding a note does not mean the correction is already in the document.
The Design gate is Designs Approved and Tests Frozen. Once frozen, the test suite is the contract the build must meet. The tests must not be changed just to make failing code pass.
If something is still outstanding
If a document is missing, check whether it was excluded from scope. If Freeze Suite is unavailable, check whether the suite is already frozen. Review any outstanding test cases or gaps in acceptance-criteria coverage before continuing.
If an agreed requirement needs to change after freezing, treat it as a design change. Unfreeze Suite requires a reason; it is not a shortcut for getting a failed test to pass.
The approval steps depend on your project template, so follow the current Compass guidance rather than repeating actions simply to make the boxes tick. For an existing project, use the document statuses and Freeze History to check what has already happened.
The designs, decisions, approvals, training documents, test cases and data plan stay with the project. Together, they provide the record of what was agreed before the build started.