Keeping track of Business Central setup data in GitHub

I have been working on a way to handle setup data using the same tools as developers are managing source code on GitHub. Imagine having setup data with a proper history of changes organized in branches. Check out the video:

https://youtu.be/phtnjASyU7g

In this video, Erik introduces an innovative concept he’s been developing: tracking Business Central setup data using GitHub as a version control system. He walks through a working prototype built into his Toolbox app, demonstrating how you can serialize table data to JSON, commit it to branches, and switch between different data configurations—essentially treating setup data as source code.

The Problem: Setup Data Chaos

The idea was born during a discussion with consultants working on a customer go-live project. There were multiple sandboxes, different versions of setup data, and configuration packages floating around with no clear way to manage them. Erik noticed a stark contrast:

  • Code side: Streamlined with branches for different sandboxes, pull requests, and merges to move code into production
  • Data side: No equivalent tooling—setup data was scattered across environments with no version control

This led to a simple but powerful question: What if we could use GitHub to track customer setup data? Not all data—just the relevant setup pieces like payment terms, currencies, shipment methods, locations, and company information.

The Toolbox App

Before diving into the demo, Erik gives a quick overview of his Toolbox app (available on AppSource). The Toolbox lets you write and execute AL code directly on a Business Central system without needing to fire up VS Code, download symbols, and deploy an app. It also supports batch processing, search and replace, table inspection (including tables you normally can’t open in edit mode), and copying data between environments.

Many Toolbox features started as experimental videos on Erik’s channel, and this GitHub data tracking feature follows the same pattern—starting as an exploration and evolving into a full feature.

The Core Concept: Treat Setup Data as Code

The fundamental idea is straightforward: serialize Business Central setup tables to JSON files and commit them to a GitHub repository. Each branch in the repository can represent a different environment (production, UAT, sandbox), and you can switch between branches to load different data configurations.

Demo Walkthrough

Setting Up the Repository

Erik starts by creating a new private GitHub repository called “demo-data” with a README file. In the Toolbox, he has already configured his GitHub account credentials using a personal access token.

Adding Tables and Committing

From the “Data in GitHub” page in the Toolbox, Erik connects to the demo-data repository and retrieves its branches. The system finds the main branch with no tables yet. He then adds the Company Information table and commits it to GitHub.

Looking at the repository in GitHub, we can see the commit from Business Central containing a new file: a JSON representation of table 79 (Company Information). The JSON format is designed to be both machine-readable and human-readable:

{
  "tableNo": 79,
  "records": [
    {
      "fields": [
        {
          "f33": {
            "fieldName": "...",
            "fieldType": "...",
            "value": "..."
          }
        }
      ]
    }
  ]
}

Each field is identified by its field number (e.g., “f33”), with additional metadata for the field name and type. The system only truly needs the field number key and the value—the rest is there for human readability. Importantly, this format works across localizations.

Working with Branches

Erik then creates a UAT (User Acceptance Test) branch in GitHub. Back in the Toolbox, he retrieves branches and sees both “main” and “uat.” He switches to the UAT branch, which replaces the data in the tracked tables with the data from that branch.

After modifying data in Business Central (changing the Address 2 field to indicate the UAT branch), he commits again. The system tracks commit timestamps against when tables were last modified, showing an exclamation point status when local data is newer than the last commit.

Switching Between Branches

The real power becomes apparent when switching branches. Erik demonstrates switching from UAT back to main—the Company Information data reverts to the main branch values. Switch to UAT, and the UAT-specific data loads in. This is essentially git checkout but for Business Central setup data.

Adding Multiple Setup Tables

Erik also demonstrates adding multiple tables at once—payment terms, currencies, shipment methods, and locations—then committing them all to a branch. This represents the typical set of setup data you’d configure during an implementation project.

Envisioned Workflow

  1. Work in a sandbox environment, building up setup data
  2. Add the relevant setup tables to a GitHub branch and commit
  3. When ready for production (or another environment), connect the Toolbox to the same repository
  4. Select the appropriate branch and pull the data into the current company
  5. Setup data is now under version control with full history and diff capabilities

Open Questions and Feature Ideas

Erik is actively seeking community feedback on several points:

  • Table recorder: Should there be a “start recording” feature that tracks which tables you modify, so you can easily add them to the current branch?
  • Selective commits: The ability to commit only certain tables rather than all tracked tables at once
  • Branch visibility: Showing which branch you’re currently on more prominently in the UI
  • Granularity: More fine-grained control over what gets committed and pulled
  • Naming: Even the feature name “Data in GitHub” is still up for discussion

Conclusion

This is a compelling concept that bridges a real gap in Business Central implementation workflows. While code deployment has mature version control practices, setup data has traditionally been managed through configuration packages and manual processes. By leveraging GitHub’s branching model, diff capabilities, and collaboration features, Erik’s approach brings the same rigor to data management. The feature is planned for inclusion in the Toolbox app, and Erik is actively soliciting community feedback to shape its development. If you’ve ever struggled with managing setup data across multiple Business Central environments, this could be a game-changer.

Picture of hougaard

hougaard