Follow me down the rabbit hole while I’m poking around to see how the GPT functionality was added to Business Central.

In this video, Erik dives into the GPT/Copilot functionality that Microsoft has built into Business Central, exploring how it works under the hood. He reverse-engineers the feature by examining the system app source code on GitHub, attempts to add the Entity Text fact box to a custom Customer Card, subscribes to the necessary events, and discovers the Azure OpenAI configuration requirements. This is a live exploration — no rehearsal — which makes the journey all the more interesting.
Copilot on the Item Card
The starting point is the Item Card in Business Central. There’s a new “Marketing Text” section that appears as a fact box with a distinctive animated border — something Erik notes he hasn’t seen elsewhere in Business Central. Clicking “Create with Copilot” (Microsoft’s branding for their GPT integration) generates a marketing description based on the item’s attributes.
For example, on a “Paris Guest Chair – Black” item, Copilot generates text like: “The Paris Guest Chair Black is the perfect way to achieve Parisian style in your office. This elegant chair is crafted with a leather seat…” — pulling in dimensions, materials, and other attributes from the item record. You can also edit the generated text in a larger editor view.
Where Does the Code Live?
Erik identifies that the Entity Text Fact Box Part is page 2011, and importantly, it lives in the System App — not the Base App. This is a significant distinction because it means the core GPT integration is at the system level.
Navigating to the ALAppExtensions repository on GitHub, under Modules/System/Entity Text, Erik finds several key objects:
- Azure OpenAI Implementation — a codeunit handling the actual API communication
- Copilot Information — a page for the Copilot administration
- Entity Text — the core codeunit (2010) with subscribable events
A critical observation: the implementation codeunit is marked as Access = Internal, meaning external developers cannot directly call the Azure OpenAI completion endpoints. Microsoft has kept the “fun stuff” outside of AL’s public reach — at least for now.
Attempting to Add Copilot to the Customer Card
Erik’s experiment is straightforward: can we add the same Entity Text fact box to a Customer Card? He starts building it out. Here’s the basic structure of the Customer Card he’s working with:
page 50100 "Customers"
{
PageType = Card;
SourceTable = Customers;
layout
{
area(Content)
{
group("Customer Information")
{
field("No."; Rec."No.")
{
ApplicationArea = All;
}
field("Name"; Rec."Name")
{
ApplicationArea = All;
}
field("Address"; Rec."Address")
{
ApplicationArea = All;
}
}
}
}
}
And the underlying Customer table:
table 50100 "Customers"
{
DataClassification = ToBeClassified;
fields
{
field(1; "No."; Code[20])
{
DataClassification = ToBeClassified;
}
field(2; "Name"; Text[100])
{
DataClassification = ToBeClassified;
}
field(3; "Address"; Text[100])
{
DataClassification = ToBeClassified;
}
}
keys
{
key(PK; "No.")
{
Clustered = true;
}
}
}
Following the pattern from the Item Card, Erik adds the Entity Text Fact Box Part (page 2012) to the Customer Card’s FactBoxes area, calling SetContext on the OnAfterGetCurrentRecord trigger — passing in the customer’s System ID, a table reference of Database::Customer, and placeholder text for the marketing description.
Subscribing to the Entity Text Events
When first deploying to a cloud sandbox, Erik gets an error: “There is no handler to provide information for this entity. Contact your partner.” This tells us that we need to subscribe to events on the Entity Text codeunit (2010) to supply the facts that Copilot uses to generate text.
Erik creates a subscriber codeunit to handle the event. The key event provides several parameters to work with:
- Source System ID — identifies which record we’re generating text for
- Source Table ID — lets us filter so we only handle our entity (Customer)
- Facts — a dictionary where we add the data points Copilot should use
- Text Tone — options like Neutral, Inspiring, etc.
- Text Format — such as Paragraph
- Handled — a boolean we set to true so the system knows we’ve provided the data
The approach is to look up the Customer by System ID and then feed relevant facts into the dictionary:
// Pseudocode for the event subscriber
// (Erik builds this live in the video)
// Filter: only handle Customer records
if SourceTableId <> Database::Customer then
exit;
// Get the customer record
Customer.GetBySystemId(SourceSystemId);
// Supply facts for GPT to work with
Facts.Add('Name', Customer.Name);
Facts.Add('Address', Customer.Address);
Facts.Add('City', Customer.City);
Facts.Add('Current Balance', Format(Customer.Balance));
// Set the generation parameters
TextFormat := TextFormat::Paragraph;
TextTone := TextTone::Inspiring;
Handled := true;
The Azure OpenAI Configuration Roadblock
After deploying and attempting to generate text, Erik hits a configuration wall. The system displays: “The service needs to be configured in the organization settings page. Would you like to open it?”
Opening the settings page reveals fields for:
- Endpoint — the Azure OpenAI service URL
- Model — which GPT model to use
- Secret — the API key
This confirms an important architectural decision by Microsoft: you cannot piggyback on Microsoft’s own Azure OpenAI key. While the built-in Item Card marketing text feature works out of the box (using Microsoft’s key), any custom implementation requires your own Azure OpenAI subscription. Erik notes he has applied for one but hasn’t received access yet, as Azure OpenAI access is distributed on a priority basis.
A Side Note on AL Copilot in VS Code
Erik takes a brief but passionate detour about the Copilot integration in Visual Studio Code for AL development. His core argument: IntelliSense and Copilot should work together, not as two independent systems competing for the developer’s attention. When IntelliSense knows there are exactly four valid options for a parameter, it should feed those to Copilot so it can suggest the most appropriate one — rather than Copilot sometimes offering completely irrelevant suggestions that conflict with what the language engine knows is valid.
The App Configuration
For reference, here’s the app.json configuration Erik is using for this experiment:
{
"id": "31532365-86ae-46a4-a27a-bfef9b5462ec",
"name": "ChatGPT",
"publisher": "Default publisher",
"version": "1.0.0.0",
"brief": "",
"description": "",
"privacyStatement": "",
"EULA": "",
"help": "",
"url": "",
"logo": "",
"dependencies": [],
"screenshots": [],
"platform": "1.0.0.0",
"application": "21.0.0.0",
"idRanges": [
{
"from": 50100,
"to": 50149
}
],
"resourceExposurePolicy": {
"allowDebugging": true,
"allowDownloadingSource": true,
"includeSourceInSymbolFile": true
},
"runtime": "10.0",
"features": [
"NoImplicitWith"
]
}
Key Takeaways
- The Entity Text framework is in the System App, meaning it’s designed to be reusable across different entities — not just items.
- You can add the Copilot fact box to custom pages by adding the Entity Text Fact Box Part and subscribing to the appropriate events on the Entity Text codeunit.
- The Azure OpenAI implementation codeunit is internal — you can’t directly call the completion APIs from your own AL code.
- Custom implementations require your own Azure OpenAI key — Microsoft’s built-in key only works for their own first-party features.
- The event-driven architecture is promising — by subscribing to Entity Text events and providing facts, you let the framework handle the GPT prompt engineering and API communication.
- BC22 introduced changes — the event signature differs between BC21 and BC22, with BC22 using identifiers instead of plain text for some parameters.
Conclusion
While Erik wasn’t able to complete the full round-trip (generating text for a customer record) due to the Azure OpenAI key requirement, this exploration reveals a lot about how Microsoft has architected GPT integration in Business Central. The framework is clearly designed with extensibility in mind — the event subscription model for providing entity facts is clean and follows established patterns. The main barrier for developers right now is obtaining Azure OpenAI access. Once that’s in place, the pieces are all there to add AI-generated text to virtually any entity in Business Central. Stay tuned for the follow-up video where Erik plans to complete the implementation with a proper Azure OpenAI key.