Business Central 2026 Wave 2: Preview Images Directly in the Web Client

One of the most practical user experience enhancements in Dynamics 365 Business Central 2026 Release Wave 2 (BC29) is the ability to preview image attachments directly in the web client without downloading them first. This feature brings image files in line with the PDF preview experience introduced in earlier releases and makes working with attachments much more seamless.

What's New?

With BC29, users can open supported image attachments directly within Business Central and view them in a dedicated preview window. There's no need to download the file locally before viewing it.

The viewer experience is similar to the existing PDF and print preview experiences. Users can zoom, navigate, print, and download the image if they want to keep a local copy.

Supported Image Formats

Microsoft has included support for a wide range of image types:

• JPEG / JPG
• PNG
• BMP
• SVG
• WEBP
• ICO
• GIF (including animated GIFs)
• AVIF (including animated AVIFs)

Safari users also gain support for:

• TIFF
• TIF

 

Additional Benefits

Beyond simply opening images, Microsoft has included a couple of nice enhancements:

Animated GIF Support

GIF thumbnails can now be displayed in FactBoxes, including animation support for GIFs up to 48 frames.

Clickable Thumbnails

Image thumbnails and PDF thumbnails become clickable and automatically open the preview window.

These small improvements make document-heavy processes much more user friendly. 

Where This Helps

This feature can be useful in many scenarios:

• Product images
• Item catalogs
• Quality inspection photos
• Purchase documentation
• Service department attachments
• Employee receipts and supporting documents
• Images generated or uploaded by custom extensions

Instead of downloading multiple files while reviewing records, users can quickly preview them directly inside Business Central.

What About Custom Extensions?

The good news is that Microsoft has made this capability available to extension developers.

For Business Central Online, developers can use:

File.ViewFromStream(...)

Customization Example: Preview an Image Stored in a Custom Table/Field

Suppose you've added a custom Table/field and want users to preview the image directly without downloading it.

Table 

table 50100 "Image Test"

{

Caption = 'Image Test';

DataClassification = CustomerContent;

fields

{

field(1; "No."; Code[20])

{

Caption = 'No.';

}

field(10; Description; Text[100])

{

Caption = 'Description';

}

field(20; "File Name"; Text[250])

{

Caption = 'File Name';

}

field(30; "Image Blob"; Blob)

{

Caption = 'Image';

}

}

keys

{

key(PK; "No.")

{

Clustered = true;

}

}

}

page 50100 "Image Test List"

{

Caption = 'Image Test List';

PageType = List;

SourceTable = "Image Test";

UsageCategory = Lists;

ApplicationArea = All;

layout

{

area(Content)

{

repeater(Group)

{

field("No."; Rec."No.")

{

ApplicationArea = All;

}

field(Description; Rec.Description)

{

ApplicationArea = All;

}

field("File Name"; Rec."File Name")

{

ApplicationArea = All;

Editable = false;

}

}

}

}

actions

{

area(Processing)

{

action(UploadImage)

{

Caption = 'Upload Image';

ApplicationArea = All;

Image = Import;

Promoted = true;

PromotedCategory = Process;

trigger OnAction()

var

FileName: Text;

InS: InStream;

OutS: OutStream;

begin

if UploadIntoStream(

'Select Image',

'',

'All Files (*.*)|*.*',

FileName,

InS)

then begin

Clear(Rec."Image Blob");

Rec."Image Blob".CreateOutStream(OutS);

CopyStream(OutS, InS);

Rec."File Name" := FileName;

Rec.Modify(true);

Message('File uploaded: %1', FileName);

end;

end;

}

action(PreviewImage)

{

Caption = 'Preview Image';

ApplicationArea = All;

Image = View;

Promoted = true;

PromotedCategory = Process;

trigger OnAction()

var

InS: InStream;

begin

Rec.CalcFields("Image Blob");

if not Rec."Image Blob".HasValue() then

Error('No image uploaded.');

if Rec."File Name" = '' then

Error('No filename stored.');

Rec."Image Blob".CreateInStream(InS);

File.ViewFromStream(

InS,

Rec."File Name"

);

end;

}

}

}

} 

 

When the user selects Preview Image, the image opens directly inside the BC29 web client without downloading it first.

Why This Matters for Developers

Prior to this feature, many developers had to rely on:

• JavaScript control add-ins
• SharePoint previews
• Temporary downloads
• External viewers

With native image preview support now built into the platform, custom solutions become simpler, cleaner, and more consistent with the standard Business Central user experience. 

Final Thoughts

The new Preview Images Directly in Web Client feature is one of those enhancements that users will immediately appreciate. It removes unnecessary downloads, provides a familiar viewing experience, and gives developers a standard way to surface image content directly within Business Central.

Combined with support for animated GIFs, clickable thumbnails, and extension development support through File.ViewFromStream, this feature helps make Business Central's document experience more modern and productive.

BC 29 lets a single index span base table and table extension fields

 Business Central 2026 release wave 2 removes a constraint that has shaped how we index extended tables since table extensions existed. In version 29, a key defined in a table extension can contain fields from the base table and fields from the extension at the same time.

That sounds small. In practice it retires one of the most common workarounds in AL development.

The constraint

Microsoft Learn has always been clear about this one. Keys defined in a table extension are secondary keys, because a table extension inherits the primary key of the table it extends. Those secondary keys can include fields from the base table, or fields from the table extension, but a single key cannot include fields from both. Each key has to be all base table fields or all fields from the extension in which it is defined.

Version 18 improved half of the problem. Before that, you could only build keys on the fields your extension added. From version 18 onward you could also add a key on fields that already existed in the base table, which solved a real category of performance issues. The standard example is External Document No. on posted document tables, where the base app key combines it with another field and a direct lookup has no useful index.

What version 18 did not solve is the mixed case. And the mixed case is the one that keeps coming up in real projects.

What the scenario looks like

Say you add a Region Code field to Sales Invoice Header for a customer with a regional reporting requirement. A user wants a list filtered by Sell-to Customer No. and sorted by Region Code, on a table with a few million rows.

Sell-to Customer No. lives in the base table. Region Code lives in your extension. You cannot put them in one key.

Why the constraint existed

This was never a Business Central design decision. It was SQL.

Under the old data model, fields added by table extensions were stored in a companion table, separate from the base table, joined at read time on the primary key. Version 23 improved that by consolidating all extensions to a table into a single companion table, so the server never needed more than one join instead of one per extension. But there were still two physical tables.

SQL Server cannot build a single index across two tables. That is the entire reason a key could not mix base fields with extension fields. The platform was passing the database's answer back to you.

Version 29 changes the storage. According to the release notes, all fields on an AL table are now stored in the same table in the database, and Microsoft attributes the new cross-boundary key capability directly to that change.

Once the fields are physically together, the objection disappears. One table, one index, no problem.

How to verify it yourself

You do not need to wait for the on-premises release to check this, and you do not need database access. The test is a compile.

tableextension 60400 "MPA Sales Invoice Header" extends "Sales Invoice Header"

{

    fields

    {

        field(60400; "Region Code"; Code[20])

        {

            Caption = 'Region Code';

            DataClassification = CustomerContent;

        }

    }

 

    keys

    {

        // "Sell-to Customer No." belongs to the base table, owned by the

        // Base Application. "Region Code" is declared right here.

        // One key, fields from both sides of the boundary.

        key(CustomerRegion; "Sell-to Customer No.", "Region Code") { }

    }

}

Compile it twice, once against symbols from a version 28 sandbox and once against symbols from a version 29 preview sandbox. On version 28 this fails, which is the documented behaviour and what makes the comparison meaningful.

BC28:

The property 'CustomerRegion' can only be set if the specified fields are from the same table.ALAL0423

Key CustomerRegion: "Sell-to Customer No.", "Region Code" 

BC29:

What this changes in practice

Some slow lists become fixable without a redesign. Any place a user filters on a standard field and sorts on yours, or the reverse, is now an indexing problem rather than an architecture problem.

Reporting extractions get simpler. Custom analysis views and extracts that combine base and extension fields have had no supported index path. Now they do.

 

What to be careful about

The constraint going away does not make indexes free.

There is still a limit of 40 keys per table. That limit predates this change and has not moved. Cross-boundary keys are about to look very attractive, and on a popular table with several apps installed, that budget gets consumed faster than anyone plans for.

Every index costs writes. An index that makes one list fast makes every insert and modify on that table slower. On Sales Invoice Header, Item Ledger Entry, or G/L Entry, that is not a theoretical cost. Measure the write path, not only the read you were trying to fix.

Adding an index to a base table means building it during schema sync. On a large production table, that is an upgrade window question rather than a deployment detail. Test the install time on a copy of real data volumes, not on Cronus.

Nobody owns the aggregate. Nothing stops three separate apps each adding a cross-boundary index to Customer. Each decision is defensible on its own, the write cost is shared, and no single publisher sees the whole picture. If you build for multiple ISV environments, this belongs on the list of things you check.

Where this sits right now

The version 29 public preview runs from the first week of September until general availability in the first week of October 2026, and it applies to online sandbox environments only. Not production, not on-premises. Microsoft has said on-premises detail will be added to the documentation when 29.0 goes generally available, and preview sandboxes are deleted around thirty days after that.

So none of this is production guidance yet. But the compile test can be run today, it costs almost nothing, and it answers the question well before anyone gets to look at the SQL. If you maintain apps that extend high volume tables, it is worth knowing now which of your workarounds you are about to be able to delete.

 

Recently Used Lookup Values Improve Everyday Productivity (BC29)

One of the practical usability enhancements coming in Dynamics 365 Business Central 2026 Release Wave 2 (BC29) is the new Recently Used in Lookups feature.

While it may seem like a small change, it addresses a common activity that users perform throughout the day: searching and selecting records from lookup fields.

What's New?

Business Central now surfaces recently used records directly within lookup dialogs. When users open a lookup, Business Central can display records they have recently searched for or selected, allowing them to find frequently used values faster without repeatedly performing the same search. The suggestions are personalized to each user based on their usage patterns.

Feature details in update 29.0 public preview for 2026 release wave 2 - Business Central | Microsoft Learn 

Where You'll Notice It

This enhancement can be useful anywhere lookup fields are commonly used, including:

• Customers
• Vendors
• Items
• Locations
• Dimensions
• Country/Region Codes
• Payment Terms

Users who repeatedly work with the same records can access them more quickly, reducing clicks and data entry time.

Example Scenario

Consider a purchasing agent who frequently creates purchase orders for the same vendors.

Before BC29

1.    Open Vendor lookup

2.    Search for vendor

3.    Select vendor

With BC29

1.    Open Vendor lookup

2.    Switch to Recent

3.    Select vendor

The feature helps reduce repetitive searching and streamlines everyday tasks.

Benefits

Faster Data Entry

Frequently used records are easier to find, reducing repetitive searches.

Personalized Experience

Each user sees recommendations based on their own activity and usage patterns. 

Improved Efficiency

Users can spend less time searching and more time processing transactions.

Consistent User Experience

The feature leverages the same underlying intelligence used by other Business Central experiences, providing a more consistent and responsive user interface. 

Not Limited to Lookups

During testing, I also noticed that recently used records can be influenced by records accessed through Global Search, not just records selected from lookup dialogs. This helps make the recommendations more relevant by reflecting how users actually navigate and work within Business Central.

A Couple of Wishes for Future Enhancements

While the feature is a welcome addition, there are a couple of improvements that could make it even better:

• Include manually entered values in the Recent list. Currently, values entered directly into a field do not appear in Recent. Including successfully validated manual entries would better reflect how many experienced users work within Business Central.
• Show Recent records by default. Instead of requiring users to switch to the Recent view each time, an option to open lookups directly on recently used records could further reduce clicks and improve productivity.

Final Thoughts

The new Recently Used in Lookups feature is a simple but valuable enhancement in Business Central 2026 Wave 2. By surfacing recently selected records directly within lookup dialogs, Microsoft is making everyday navigation and data entry faster and more intuitive.

It may not be the biggest feature in BC29, but for users who spend their day creating transactions and maintaining records, the time savings can quickly add up.

Public Preview for Business Central 29.0 (2026 Release Wave 2) Is Here

 The preview environments for Business Central 2026 release wave 2 are now rolling out globally. If you have access to the Business Central admin center, you can spin up a sandbox on version 29.0 today and start looking at what is coming.

Microsoft's announcement and the full details are here: aka.ms/BCMajorUpdates

What this actually is

Twice a year, Business Central gets a major update. Wave 1 lands in April, wave 2 in October. Ahead of each one, Microsoft opens up preview environments so partners and customers can test their own apps, extensions, and integrations against the new version before it becomes the version everyone is running.

That is what just happened. Version 29.0 is the wave 2 release, and the preview build is available now.

This is not a "read the release notes and nod" moment. It is the window where you can find the thing that breaks your customer's environment and get it fixed before it becomes a production incident.

How to get a preview environment

From the Business Central admin center, go to Environments, choose New, and create a Sandbox. In the Version dropdown, pick the 29.0 preview build.

A few things worth knowing before you do:

• Create it as a Sandbox, not Production. Preview builds are for testing and nothing else.
• Preview environments are temporary. Do not build anything on one that you expect to keep.
• Localization matters. If you support multiple countries, test the ones you actually deploy to.

What to test

If you are a partner or an ISV, the list is fairly short and fairly obvious:

Your AL extensions. Recompile against the 29.0 symbols. Deprecations and breaking changes in the base application show up here first, and they show up as compile errors, which is the cheapest possible place to find them.

Your integrations. API pages, OData endpoints, web services, anything talking to Business Central from the outside. These break quietly, which makes them worse than the things that break loudly.

Your customer-specific customizations. The ones nobody has looked at in two years are the ones that will surprise you.

The new features you care about. Check the release plan on Microsoft Learn for what is in wave 2, then go poke at the features that touch your customers' processes. Reading about a feature and using it produce different opinions.

Reporting what you find

If something is broken, report it. This is the part that matters most and gets skipped most.

Bugs and feedback go here: aka.ms/BCPreviewBugs

A good report saves everyone time. Include the version number, the localization, whether it reproduces on a clean environment, and the steps to get there. If you can reproduce it without your own extensions installed, say so, because that immediately tells the engineering team it is theirs and not yours.

Why this is worth your time

The preview window is short. Once the release goes GA and your environments start updating, a problem you could have raised as a preview bug becomes a support ticket with a customer waiting on the other end of it.

The people who find the interesting problems during preview are the ones running real extensions against real data. That is you. Microsoft cannot test every combination of ISV app, custom code, and integration that exists in the field, and it does not pretend to. That is exactly why the preview exists and why the feedback loop is open.

So create a sandbox, recompile your code, and go looking for trouble. Better to find it now.

Dynamics NAV, GP and SL: Why I Think Customers Should Start Planning Now

 

If you are still running Dynamics NAV, Dynamics GP, or Dynamics SL, you have probably heard the conversation about moving to Dynamics 365 Business Central.

The question I hear most often is:

"Do we really need to migrate now?"

My answer is usually: you don't necessarily need to migrate tomorrow, but you should start planning now.

I've spent many years working with Dynamics NAV, Business Central, and data migration projects. One thing I've learned is that the actual migration is rarely the hardest part.

The difficult part is deciding what should be migrated in the first place.

Don't Start With the Deadline

When Microsoft announces lifecycle changes, it is natural to look at the dates and start counting backward.

For NAV, Microsoft says the final version was released in 2017 and extended support ends in January 2028. Microsoft also has separate licensing and service-plan changes coming later, including April 30, 2031. These are different milestones, so I would not treat 2028 as a simple "NAV stops working" deadline.

For me, the more important question is not:

"How long can we continue running NAV or GP?"

It is:

"If Business Central is likely to be our next ERP, what should we be doing today to make that move easier?"

That change in thinking can make a big difference.

Your ERP Has Probably Changed a Lot Over the Years

If you've been running NAV or GP for many years, your current system probably doesn't look anything like the original implementation.

There may be:

• Customizations
• Third-party solutions
• Custom reports
• Integrations
• Historical data
• Business-specific processes
• Workarounds
• Old functionality that nobody remembers why they built

Some of those things may still be critical.

Others may no longer be needed.

And this is where I think migration projects become interesting.

Should we really move all of it?

Probably not.

I've seen situations where people start thinking about migration by creating a list of everything in the existing ERP and asking how to reproduce all of it in Business Central.

I think that's backwards.

I'd rather start with:

What does the business actually need going forward?

Migration Is an Opportunity to Clean Things Up

A migration gives you a rare opportunity to look at the ERP environment with fresh eyes.

For every customization, report, integration, and piece of historical data, I would ask:

Do we still need this?

If the answer is yes:

Does it need to work exactly the same way?

And if the answer is still yes:

Is the existing approach the best way to implement it in Business Central?

That last question is particularly important.

Business Central has a different architecture and extension model from older NAV environments. Microsoft documents supported NAV-to-Business-Central migration paths, but the existing application customizations need to be handled appropriately.

So I wouldn't approach the project as:

"Let's convert everything we have."

I'd approach it as:

"Let's understand what we have, decide what matters, and then determine the best way to build it in Business Central."

Data Is Another Big Question

The same thinking applies to data.

One of the first questions in almost every migration discussion is:

"Can we move all of our historical data?"

Technically, that isn't always the most useful question.

I'd ask:

"What data do our users actually need in Business Central?"

Maybe you need all your history.

Maybe you need master data, open transactions, and opening balances, while older history can remain in another system or reporting environment.

Maybe certain historical transactions are needed for operational reasons, while other data is required only for reporting or audit purposes.

There isn't one answer that works for every customer.

Microsoft's current migration tooling supports different data sets depending on the source system and migration scenario. For example, the GP cloud migration process can migrate setup, master data, transactional data, and historical data, while the specific data to migrate is configurable.

That doesn't mean every customer should migrate everything.

It means there are options.

GP Customers Have Migration Tools, But That Doesn't Mean the Project Is Automatic

For Dynamics GP customers, Microsoft provides built-in cloud migration capabilities for supported GP versions, including GP 2015 and later, subject to the documented prerequisites.

That's good news.

But a migration tool doesn't answer questions such as:

• Which customizations should we replace?
• Which third-party products do we still need?
• Which reports should we rebuild?
• Which integrations need to change?
• How much historical data should we keep?
• How do we validate the financial results?

The technology can help move the data.

The decisions still belong to the project team and the business.

What I Would Do If I Were Starting Today

If I were responsible for a NAV or GP environment today and Business Central was the likely destination, I wouldn't start by scheduling the production migration.

I'd start with an assessment.

I'd want to know:

1. What version are we running?

2. How much customization do we have?

3. What third-party applications are involved?

4. What integrations exist?

5. Which reports are actually being used?

6. How much data do we have?

7. Which historical data do users really need?

8. What business processes depend on custom functionality?

9. What can Business Central handle out of the box?

10. What needs to be redesigned?

Once those questions are answered, the migration strategy becomes much clearer.

Don't Wait Until You Have to Migrate

This is probably my biggest takeaway.

Starting early doesn't mean committing to a go-live date immediately.

It gives you time to:

• Understand the existing environment
• Clean up data
• Review customizations
• Evaluate third-party solutions
• Test migration options
• Identify integration changes
• Run mock migrations
• Validate the results
• Train users
• Make better decisions

Microsoft's own migration guidance emphasizes assessment, preparation, test migrations, data replication, validation, and completion as part of the migration process.

That aligns closely with what I've seen in real projects.

The more you understand before the production cutover, the fewer surprises you are likely to have.

My Takeaway

I don't think NAV, GP, or SL customers should look at Microsoft's lifecycle announcements and immediately panic about migration.

But I also don't think waiting until the last possible moment is a good strategy.

If Business Central is likely to be your next ERP, start understanding your current environment now.

Find out what you have.

Find out what you actually use.

Find out what you really need.

Then decide what should move forward.

Because in my experience, a successful ERP migration isn't about moving everything from the old system into the new one.

It's about moving the right things, leaving behind the unnecessary complexity, and taking the opportunity to build something better.

Analysis Mode killed half the Excel exports on your client's shared drive

 

Open any client's finance folder and you will find it. Six versions of the same spreadsheet. Customer Aging - Oct.xlsx, Customer Aging - Oct (2).xlsx, Customer Aging FINAL.xlsx, Customer Aging FINAL copy.xlsx. All exported from Business Central.

Nobody built that folder on purpose. It exists because someone once needed to group customer entries by salesperson and month, could not do it on the list page, and hit Open in Excel. Then they needed it again next month.

What actually happens

Hit “Enter analysis mode” and the page changes shape. The normal action bar is replaced by an analysis bar, and the screen splits into two halves.

On the left is the data area, with a summary bar along the bottom and the analysis views bar across the top. On the right are two panes: Columns and Analysis filters.

Nothing you do here touches the underlying data, and nothing you do changes the page for anyone else. That is worth saying to a nervous client before you let them click anything.

Analysis views are the point. The bar at the top starts with one view called Analysis 1. Each view holds its own columns, its own filters, its own pivot arrangement. You might have one for aged balances, one for your top twenty customers, one filtered to overdue items only. They persist between sessions; they are yours alone, and you can rename, duplicate, move, or delete them. Analysis 1 cannot be deleted, only renamed, and Delete All leaves it standing.

The Columns pane has rules. Row Groups accept non-numeric fields only: text, date, time. Values accept only fields that can be summed. Drag something into the wrong area and the client refuses.

One subtlety worth knowing: if you have personalized the page to add a field, it shows up in the Columns pane with its checkbox cleared. It is there; it is just not switched on.

Date hierarchies are generated for you. For each date field in the dataset, Business Central creates three additional fields named after it: Posting Date Year, Posting Date Quarter, and Posting Date Month. Analysing Customer Ledger Entries, you also get the same trio for Document Date, Due Date, and every other date on the page.

The hierarchy is not the field you expand into. It is three fields you stack in Row Groups, and stacking them is what produces the expandable years, quarters, and months with subtotals at each level.

Pivot mode does what you expect. Toggle it on and a Column Labels area appears alongside Row Groups and Values. Rows down the side, labels across the top, sums in the middle. Same model as Excel PivotTable, deliberately.

Note: Columns that only have a few possible values are the best candidates for use in column Values.

It reaches into related tables. “Add columns from” option on the Analysis context menu lets you pull fields in from tables related to the page's source table, and group by them.

 

And you can export the definition as JSON. Not the data, the analysis itself: columns, filters, arrangement. Which means an analysis view can be packaged into an extension and shipped to a client rather than described in a training document.

Analysis mode needs execute permission on system object 9640, Allow Data Analysis mode, normally granted through the DATA ANALYSIS - EXEC permission set. Most full users have it. Team Member and other limited roles often do not, and permission sets built years ago certainly do not. When a client says the button is not there, check this first. Five minutes, fixes it for a whole department.

Two other reasons can be missing. Developers can switch it off per page with the AnalysisModeEnabled property, so if it is absent on exactly one page, go looking there. And analysis mode is not supported on lists that use indentation, which means Chart of Accounts and the G/L Account List do not have it at all. That is unfortunate, because the Chart of Accounts is the first place a finance person will try. Have the answer ready. 

Date hierarchies use the calendar year. Not your client's fiscal year.

The generated Year, Quarter, and Month fields are built on the normal calendar. They do not know about any fiscal calendar defined in Business Central.

If your client's fiscal year starts in April, their Q1 in analysis mode is January to March and their Q1 in every financial report they have ever run is from April to June. No errors. The numbers are correct for the calendar periods they describe. They just do not match the numbers in the meeting.

Also worth knowing: the hierarchy only generates for fields of type Date. Datetime fields do not get one.

Calculated fields are the ones computed on the page rather than read from the database: running totals, percentages, conditional counts. They stop displaying in two situations. When the list goes over 100,000 rows, and whenever you add fields from a related table.

Try it yourself

Ten minutes, and you will have something worth showing a client. This is roughly Microsoft's own aged receivables example with the sharp edges labelled.

1.      Open Customer Ledger Entries and choose Enter analysis mode.

2.      In the Columns pane, clear every column at once using the checkbox beside the Search field. Start from nothing.

3.      Turn on Pivot Mode.

4.      Drag Customer Name into Row Groups and Remaining Amount into Values.

5.      Drag Due Date Month into Column labels. Twelve columns, safely inside the cardinality limit.

6.      Use Analysis filters to narrow to one year. Note that this filter lives on the view, not the page, so your other views are untouched.

7.      Rename the view to Aged Accounts by Month.

Then, to see the hierarchy properly:

8.      Add a second view. Put Posting Date Year, Posting Date Quarter, and Posting Date Month into Row Groups in that order, and Remaining Amount into Values.

9.      Expand a year, then a quarter. Watch the subtotals appear at each level and the record count beside each group.

10.                             Use Copy link from the view's dropdown. In the dialog, look at the Company field: you can link to your current company or deliberately not link to any company at all. Recipients get prompted to name their own copy of the view.