Recently while running a tenant synchronization in Microsoft Dynamics 365 Business Central (on-prem), I encountered an error during the Sync-NAVTenant process:
This error typically occurs during tenant synchronization and can halt your deployment or upgrade process. The issue stems from corrupted or incomplete metadata in the app schema snapshot table, specifically related to table extensions.
The error indicates that the $ndo$navappschemasnapshot system table contains table extension records that are missing the required appid field. This can happen due to:
Incomplete app installations or uninstallations
Failed upgrade processes
Database corruption during extension deployment
Manual modifications to extensions without proper cleanup.
The Solution
The fix involves cleaning up the corrupted table extension metadata from the schema snapshot table. Here’s the SQL query that resolves the issue:
USE [YourDatabaseName]
GO
DELETE FROM [$ndo$navappschemasnapshot]
WHERE (istableextension = 1)
GO
The “Missing appid on table extension metadata” error can be frustrating, but it’s usually straightforward to resolve with the SQL cleanup approach. Remember to always backup your database before making direct SQL modifications and test the solution in a non-production environment first.
If you face a similar issue during tenant sync or app upgrade, this SQL cleanup should help you recover quickly.
The rise of AI-powered coding assistants has sparked a fascinating shift in the consulting world. Functional consultants, traditionally focused on business processes and requirements, are now picking up coding tools and creating technical solutions themselves. This phenomenon, often called “vibe coding,” is reshaping team dynamics and project workflows. But is this evolution beneficial, or does it create new challenges?
What is Vibe Coding?
Vibe coding refers to the practice of using AI assistants like GitHub Copilot, ChatGPT, or Claude to write code based on natural language descriptions and high-level understanding, rather than deep technical expertise. For functional consultants who understand business requirements intimately but lack extensive programming experience, these tools offer a tempting shortcut to implementation.
Why Functional Consultants Are Embracing Code ?
1. Faster Solution Delivery
Consultants can quickly generate AL code snippets, table extensions, or API wrappers using natural language prompts. What might take hours of manual coding can be drafted in minutes. This speed is particularly useful in sandbox or prototyping phases.
2. Empowered Functional Consultants
Functional consultants, who understand business processes but may lack deep AL knowledge, can experiment with configurations or customizations. This bridges the gap between functional understanding and technical execution, leading to better collaboration.
3. Lower Entry Barrier for New Developers
For junior technical consultants, Vibe Coding serves as a teaching companion. It can suggest syntax, help avoid errors, and guide them through standard Business Central development patterns.
4. Consistency and Standardization
AI-driven code suggestions can align to best practices and Microsoft guidelines (if the tool is properly trained), ensuring consistent code quality across teams.
⚠️ The Drawbacks and Risks
1. Uncontrolled Code Generation
AI tools can produce functional code that appears correct but lacks performance optimization or security validation. If used directly in production environments, this can lead to instability or compliance issues.
2. Reduced Technical Ownership
Overreliance on Vibe Coding may cause consultants to skip the learning curve of understanding Business Central’s architecture, data model, or event-driven patterns. This can erode long-term technical expertise.
3. Audit and Governance Challenges
AI-generated code might not have clear authorship or documentation. In regulated industries, this creates challenges during audits or code reviews, especially if traceability is required.
4. Data Security Concerns
If the tool transmits prompts or metadata to external servers for AI processing, it could expose sensitive business logic or schema information. This must be reviewed against company data protection policies.
👨💻 Impact on Technical Consultants
Vibe Coding doesn’t replace technical consultants — but it changes their role:
From coders to reviewers: Technical consultants become code reviewers and architects ensuring AI-generated outputs follow best practices.
From builders to enablers: They enable functional teams by setting up safe guardrails, templates, and review processes.
From developers to strategists: With repetitive tasks automated, technical consultants can focus on design, integration, and performance tuning.
In essence, Vibe Coding shifts technical consulting toward higher-value work, provided governance and quality checks exist.
Vibe Coding represents a powerful step toward modernizing Business Central development. It can improve efficiency, empower functional teams, and streamline solution delivery — but only when implemented with strong governance, code review, and data protection policies.
Rather than diminishing the role of technical consultants, Vibe Coding highlights their importance. They become the architects and quality guardians who ensure that AI-generated work aligns with business goals, technical standards, and long-term sustainability.
Data privacy and security have become paramount concerns for businesses across all industries. With increasing regulatory requirements and growing awareness of data protection, organizations need robust yet user-friendly solutions to safeguard sensitive information. Microsoft’s Dynamics 365 Business Central Wave 2 2025 introduces a game-changing feature that addresses this challenge: the new ‘Concealed’ text field type with the innovative Mask Type property.
The Challenge: Balancing Security and Usability
Traditionally, we faced a dilemma when handling sensitive data fields. The existing ExtendedDataType = Masked property offered security by displaying field values as dots, but this approach had limitations:
Always hidden: Once masked, the data remained permanently concealed, even from authorized users
Poor user experience: Users couldn’t verify entered data, leading to potential input errors
Limited flexibility: No option to reveal data when legitimate access was needed
These limitations created friction between security requirements and practical usability, forcing developers to choose between protecting sensitive data and maintaining a smooth user experience.
Business Central Wave 2 2025 introduces the new MaskType enum property, revolutionizing how we handle sensitive data display. This property offers two distinct values:
MaskType Values Explained
None (Default)
Standard behavior where field values are fully visible in the UI
No masking or concealment applied
Suitable for non-sensitive data fields
Concealed
Field values are hidden by default, appearing as masked dots
Users can reveal the actual value through an explicit action
An interactive “eye” button appears next to the field for toggling visibility
Perfect balance between security and accessibility
Implementing the concealed field type is straightforward. Here’s how to configure it in your AL code:
Not supported: List page repeaters and grid controls
The introduction of the ‘Concealed’ text field type with the MaskType property in Business Central Wave 2 2025 represents a significant advancement in data protection capabilities. This feature successfully bridges the gap between security requirements and user experience, providing organizations with a flexible, user-friendly approach to protecting sensitive information.
With the release of Business Central 2025 Wave 1, business central continues to enhance developer and user experience in reporting and data analysis. One such powerful addition is the new property: ExcelLayoutMultipleDataSheets. This feature addresses a long-standing limitation in Excel export scenarios—allowing multiple datasets to be exported into separate sheets within a single Excel workbook.
What is ExcelLayoutMultipleDataSheets?
The ExcelLayoutMultipleDataSheets property is a new setting introduced for report objects that use Excel layouts. It enables developers to bind multiple data items or datasets to different worksheets in an Excel layout file (.xlsx), making reports more organized and structured when exported.
🧩 Structured Reports Separate sheets for different datasets make it easier for business users to navigate complex reports—such as Sales Orders on one sheet, Customer Info on another, and Totals on a summary sheet.
🛠️ Developer Control You can name your data items and match them to sheet names in your Excel layout. This gives you more granular control and reduces the need for workarounds.
How to Use ExcelLayoutMultipleDataSheets
report 50100 MyMultiSheetReport
{
UsageCategory = ReportsAndAnalysis;
ApplicationArea = All;
DefaultRenderingLayout = MyExcelLayout;
ExcelLayoutMultipleDataSheets = false; // Global setting is to use a single sheet
dataset
{
dataitem(Customer; Customer)
{
column(CustomerNo; "No.") { }
column(CustomerName; Name) { }
}
dataitem(Vendor; Vendor)
{
column(VendorNo; "No.") { }
column(VendorName; Name) { }
}
}
rendering
{
layout(MyExcelLayout)
{
Type = Excel;
ExcelLayoutMultipleDataSheets = true; // Override for this specific layout
}
}
}
In this example, even though the global ExcelLayoutMultipleDataSheets property for the report is set to false, the MyExcelLayout will render the output with two separate worksheets:
Data_Customer containing the customer data.
Data_Vendor containing the vendor data.
If the ExcelLayoutMultipleDataSheets property within the MyExcelLayout definition was set to false (or not specified), both datasets would be combined into a single “Data” sheet in the Excel output.
The enhancement of the ExcelLayoutMultipleDataSheets property in Business Central Wave 1 2025 offers developers greater flexibility and control over Excel report layouts. By enabling the creation of multi-sheet Excel files at the layout level, you can deliver more user-friendly and better-organized reports, ultimately empowering your users to gain deeper insights from their Business Central data.
When developing reports in Microsoft Dynamics 365 Business Central, performance and scalability are crucial—especially in cloud environments where system efficiency impacts everything from responsiveness to cost. One often-overlooked feature that can significantly enhance report performance is the DataAccessIntent property.
What Is DataAccessIntent?
The DataAccessIntent property is available on report objects in AL. It specifies how a report should access the database—whether it’s read-only or read-write.
The property supports two values:
DataAccessIntent = ReadOnly
DataAccessIntent = ReadWrite
ReadOnly
When you set DataAccessIntent = ReadOnly, you are explicitly telling the platform that your report only needs to read data from the database and will not perform any write operations.
Why is this important?
Better Performance: In Business Central SaaS, reports marked as ReadOnly can run on read-only replicas of the database. This reduces the load on the primary (read-write) database and enhances scalability.
Improved Report Execution Time: Since queries are routed to optimized replicas, report rendering can be faster and more efficient.
ReadWrite
If your report needs to modify data during execution—a rare scenario—you should use DataAccessIntent = ReadWrite. This forces the report to run on the primary database.
However, you should avoid using ReadWrite unless absolutely necessary because:
It eliminates the benefit of using read replicas.
It may degrade performance, especially under high concurrency.
By default, if you don’t specify the property, it behaves as ReadWrite. So it’s a good practice to explicitly set it to ReadOnly when applicable.
Important Considerations
The DataAccessIntent property is only a hint to the Business Central server. The server may not always be able to use a read-only replica, even if the property is set to ReadOnly.
If a report with DataAccessIntent set to ReadOnly attempts to modify data, a runtime error will occur.
The DataAccessIntent property can be overridden by the user through the “Database Access Intent List” page in Business Central.
In short: if your report doesn’t write data, use DataAccessIntent = ReadOnly. It’s an easy win for performance and best practice compliance.
When building customizations or integrations in Microsoft Dynamics 365 Business Central, performance is often a key concern—especially when working with large datasets. One powerful tool for improving performance is the SETLOADFIELDS method on record variables.
🚀 What is SETLOADFIELDS?
In Business Central, when you retrieve a record (using FIND, GET, NEXT, etc.), all fields of the record are loaded from the database by default. This includes fields you might never use, such as FlowFields (which are calculated on the fly). This can lead to unnecessary memory usage and slower data retrieval.
SETLOADFIELDS tells the system which fields to load, so it skips the rest. This can dramatically improve performance, particularly when:
You’re looping through large datasets
You’re only using a few fields per record
Your table includes FlowFields or BLOBs
📘 Syntax
Rec.SETLOADFIELDS(Field1, Field2, ...);
You place this line before reading the records. This tells the AL runtime engine to load only the specified fields when the records are retrieved.
Let’s say you need to loop through all items and check their No. and Inventory:
Item.SETLOADFIELDS("No.", Inventory);
if Item.FINDFIRST then
repeat
if Item.Inventory > 0 then
// do something
until Item.NEXT = 0;
Use SETLOADFIELDS only when needed – Overusing it without understanding the data flow may result in missing fields or unexpected behavior.
Calling CALCFIELDS still works – You can still explicitly calculate FlowFields after using SETLOADFIELDS.
Resets on modification – If you call MODIFY, INSERT, or VALIDATE, the load fields context is reset. Use SETLOADFIELDS again if necessary.
BLOB and FlowFields – Avoid loading BLOBs and FlowFields unless absolutely necessary. SETLOADFIELDS helps you skip them efficiently.
👨💻 Summary
Feature
Without SETLOADFIELDS
With SETLOADFIELDS
Data Loaded
All fields
Only specified fields
Memory Usage
High
Lower
Speed
Slower
Faster
By leveraging SETLOADFIELDS, developers can significantly optimize the performance of their AL code in Business Central. It’s a small addition that can make a big difference in speed and scalability.
Avoid it when doing full record operations like MODIFY, unless you’re confident about which fields are required.
When working with filters and record ranges in AL , two handy functions often come into play: GETRANGEMIN() and GETRANGEMAX(). These functions help you programmatically access the lower and upper bounds of a filter applied to a field in a record. This can be especially useful for creating reports, processing data, or passing filters between records.
What are GETRANGEMIN() and GETRANGEMAX()?
These two functions are part of the Record data type and help retrieve the range boundaries for a specific field filter.
GETRANGEMIN(Field): Returns the lowest value in the filter range for the specified field.
GETRANGEMAX(Field): Returns the highest value in the filter range for the specified field.
If there is no filter set for the field, both functions return blank.
IF (SalesHeader.GETRANGEMIN("Posting Date") < AllowedStartDate) OR
(SalesHeader.GETRANGEMAX("Posting Date") > AllowedEndDate) THEN
ERROR('Filter range is outside allowed period.');
The GETRANGEMIN() and GETRANGEMAX() functions are powerful tools when working with dynamic filters in AL. They enable developers to write cleaner, more adaptable code by directly accessing the boundaries of filter conditions.
In today’s fast-paced business environments, performance optimization is not a luxury — it’s a necessity. Whether you’re building custom reports, extending pages, or writing integration APIs in Microsoft Dynamics 365 Business Central, slow operations can frustrate users and strain resources.
One simple but powerful technique to improve performance is using the SetAutoCalcFields method.
Why FlowFields Matter for Performance
In Business Central, FlowFields are virtual fields calculated on the fly, not stored physically in the database. Examples include:
Inventory on Item
Balance on Customer
When you retrieve a record, FlowFields are not calculated automatically unless you explicitly call CalcFields().
Manually calculating FlowFields for every record during loops, leading to multiple SQL queries — one for each record — causing heavy load and slower performance.
SetAutoCalcFields solves this by batch-calculating FlowFields along with the record fetch. Instead of running one query per record, it combines the calculation in a single optimized query.
Imagine fetching 1,000 customers and displaying their balances without SetAutoCalcfields:
CustomerRec.FindSet();
repeat
CustomerRec.CalcFields(CustomerRec.Balance); // Triggers a DB call every time!
DisplayBalance(CustomerRec."No.", CustomerRec.Balance);
until CustomerRec.Next() = 0;
Result:
1 SQL query to get Customers
+ 1,000 SQL queries for Balances
With SetAutoCalcFields:
CustomerRec.SetAutoCalcFields(CustomerRec.Balance);
CustomerRec.FindSet();
repeat
DisplayBalance(CustomerRec."No.", CustomerRec.Balance);
until CustomerRec.Next() = 0;
Result:
1 SQL query to get Customers and Balances together
Benefits of Using SetAutoCalcFields
Improved Page Load Times: By deferring calculations, pages with numerous records and calculated fields will load significantly faster.
Faster Report Generation: Reports that rely on calculated fields will be generated more quickly as the calculations are performed only when the field’s value is actually needed for display or processing.
Reduced Database Load: Fewer automatic calculations translate to fewer database queries, reducing the overall load on your Business Central database.
Enhanced User Experience: Snappier performance leads to a more responsive and enjoyable user experience.
Best Practices for Performance Gains
To maximize the benefits of SetAutoCalcFields:
Only specify necessary FlowFields: Don’t auto-calculate every FlowField — focus on what your process needs.
Use it before data retrieval: Call SetAutoCalcFields beforeFindSet(), FindFirst(), or FindLast()
Avoid unnecessary recalculations: Once FlowFields are set to auto-calculate, do not manually call CalcFields() again for the same fields.
Monitor heavy FlowFields: Some FlowFields (e.g., Inventory) involve complex sums across tables — only auto-calculate when really needed.
Profile your code: Use Performance Profiler to measure improvements.
Using SetAutoCalcFieldsproperly can lead to dramatic performance improvements in Business Central. By reducing SQL traffic, simplifying code, and batch-fetching FlowFields intelligently, you can create faster, cleaner, and more scalable applications.
A small change in your coding habits can create a big impact for your users.
With the release of Microsoft Dynamics 365 Business Central Wave 1 2025, it continues to refine the AL development experience — and one of the key improvements is the ability to obsolete report layouts cleanly and officially.
If you’re managing a growing list of custom layouts or updating reports across multiple extensions, this new feature will help you deprecate old layouts safely, keep your solution clean, and guide developers or users toward better alternatives.
Why Obsoleting Layouts Matters
In real-world implementations, layouts evolve:
Data fields change.
Users request better designs.
Old layouts become unsupported.
Without a proper way to deprecate these layouts, organizations risk:
Confusion about which layout to use
Broken printouts
Technical debt piling up over time
Now, with Wave 1 2025, you can mark layouts as obsolete similarly to how you obsolete fields, tables, or procedures.
ObsoleteState: Can be Pending (warning) or Removed (error).
ObsoleteReason: Brief explanation for developers/users.
ObsoleteTag: Identifies when/why it was marked obsolete (your own versioning or tag).
What Happens to Users When a Layout is Obsoleted?
ObsoleteState = Pending:
Users and developers get compiler warnings.
The layout is still selectable and usable.
ObsoleteState = Removed:
The system throws compiler errors if any report layout tries to use it.
Users can no longer select it at runtime.
The ability to obsolete report layouts in Business Central Wave 1 2025 is a small but powerful feature that can dramatically improve the quality, maintainability.
Whether you’re cleaning up old customer-specific layouts or modernizing your extensions, using Obsolete State strategically will help future-proof your solutions.
With the release of Business Central 2025 Wave 1, Business Central continues to simplify AL development by introducing intuitive and developer-friendly features. One such small yet powerful enhancement is the ToText method — designed to streamline how simple type values are converted to text.
In previous versions, we developers often relied on FORMAT() for converting simple types like integers, decimals, booleans, and option values into text. While FORMAT() has been effective, it comes with localization considerations and sometimes produces inconsistent results depending on the environment or the formatting settings.
✨ What’s New: ToText Method
The new ToText method is a type extension method introduced for simple AL types. It provides a clearer, more consistent way to convert values to string representations without the overhead of full formatting logic.
Supported Types
The ToText method supports the following simple types:
Integer
Decimal
Boolean
Char
Option
Date
Time
DateTime
GUID
Let’s look at some examples of how the ToText() method can simplify your code:
var
myInteger: Integer := 42;
myDecimal: Decimal := 2.71828;
myDate: Date := TODAY;
myTime: Time := TIME(10, 30, 0);
myBoolean: Boolean := true;
myOption: Option Alpha,Beta,Gamma := Option::Beta;
integerAsText: Text;
decimalAsText: Text;
dateAsText: Text;
timeAsText: Text;
booleanAsText: Text;
optionAsText: Text;
begin
integerAsText := myInteger.ToText(); // integerAsText will be '42'
decimalAsText := myDecimal.ToText(); // decimalAsText will be '2.71828' (or similar based on locale)
dateAsText := myDate.ToText(); // dateAsText will be the default short date format
timeAsText := myTime.ToText(); // timeAsText will be the default time format
booleanAsText := myBoolean.ToText(); // booleanAsText will be 'true'
optionAsText := myOption.ToText(); // optionAsText will be 'Beta'
Message('Integer: %1', integerAsText);
Message('Decimal: %1', decimalAsText);
Message('Date: %1', dateAsText);
Message('Time: %1', timeAsText);
Message('Boolean: %1', booleanAsText);
Message('Option: %1', optionAsText);
end;
Prefer ToText() when you want predictable results across environments (e.g., when storing values in logs or metadata).
Continue using FORMAT() when you need locale-aware output, such as in printed documents or user-facing formatted messages.
It simplifies the process of converting simple data types to their default text representations, leading to cleaner, more readable, and potentially more efficient code. While FORMAT() remains the go-to for advanced formatting needs, ToText() will undoubtedly become a frequently used tool in your Business Central development.
Ammolh Saallvi Blog 