GoLive Checks is a Business Central extension for go-live readiness validation. The idea is simple: before a customer goes live, you run a set of automated checks against their migrated data in a sandbox environment. Each check produces a pass/fail/warning result that tells the consultant exactly what still needs attention.

This is not unit testing your code. It is data validation: verifying that the customer's chart of accounts is configured correctly, that their item/location combinations can actually post, that their opening balances match expectations. The BC test framework (TestRunner + [Test] codeunit isolation) gives us a clean, transaction-safe way to do this — including checks that post and roll back — without any additional infrastructure.

This repo is a structured teaching vehicle, built for a junior developer/consultant who:

• Has basic AL/BC development knowledge (can read and modify codeunits and tables)
• Has implemented BC companies and understands the business domain
• Wants to learn proper extension architecture patterns while doing useful work

The framework is already built. The junior's job is to understand it, then extend it.

src/
  Core/          — Framework engine (don't modify these)
  Interfaces/    — IGLCCheck and IGLCRecordFilter contracts
  Enums/         — Check type and filter type dispatch enums
  Tables/        — Data model
  Filters/       — Filter strategy implementations
  Checks/        — Reference check implementations (study these)
    GeneralLedger/
    Sales/
    Items/
  Pages/         — UI layer
docs/            — This guide and future chapter content

The work a junior adds lives entirely in src/Checks/<Area>/. They also add a value to the GLC Check Type enum (or submit a PR to get one added) and register their check via a module installer codeunit.

This repo is designed to be worked through as a series of chapters, each one adding a new check module to the framework. Chapters are not documentation files — they are assignments: a brief that describes the business problem, the BC tables involved, what needs to be validated, and what the junior should produce.

Each chapter targets a different area of Business Central and a different level of complexity. The structure progresses from reading-only checks (simple counts, boundary validation) toward transactional checks (post-and-rollback) and eventually toward richer filter-driven checks.

Chapters are intentionally open-ended at the implementation level. The junior researches the BC business logic themselves and documents what they learned alongside the code. That documentation becomes part of the PR, because understanding why something matters at go-live is as important as the code itself.

Each chapter has a folder in docs/. Start with the 00-intro.md in each folder.

Every check is three things:

1. An enum value — add it to GLCCheckType.Enum.al pointing at your codeunit
2. A check codeunit — implements six methods (Run, RunRollback, RequiresRollback, GetDefaultParameters, GetArea, GetDescription)
3. A module installer codeunit — subscribes to OnInstallGLCChecksPerCompany and registers your category, subcategory, step, default parameters, and parameter labels

The check codeunit writes results by calling:

ResultHandler.CacheResult('...');   // success
ResultHandler.CacheWarning('...');  // warning
ResultHandler.CacheError('...');    // failure

For transactional checks (anything that posts), set RequiresRollback() = true and implement RunRollback() as a one-liner:

procedure RunRollback(var GLCCheckParameters: Record "GLC Check Parameters"): Boolean
var
    GLCUtilities: Codeunit "GLC Utilities";
begin
    GLCUtilities.RunInIsolation("GLC Check Type"::YourCheckType, GLCCheckParameters);
end;

The framework handles everything else: the TestRunner isolation, the in-memory result handoff, and persisting results to the database after rollback.

The old version of this tool depended on Microsoft's test libraries (Library Assert, Library Inventory, etc.). Those libraries are convenient for unit tests but they:

• Cannot be deployed to a customer sandbox without manual setup
• Introduce large, unrelated dependencies
• Drift between BC versions

This version uses only standard AL and BC base app objects. It runs in any BC 22+ sandbox or cloud environment with no additional setup beyond deploying the extension.

Assign the GLC All permission set to your user, then navigate to the Go-Live Readiness Role Center or search for Go-Live Checklist Categories.

• Run All Checks — runs every registered check in every category
• Run Selected Category — runs only the checks in one category
• Run Selected Subcategory — runs only the checks in one subcategory

Results persist in the GLC Test Result table and are visible via drilldown from the category/subcategory/step pages.

Chapter documents will live alongside this README in the docs/ folder.