Update 28.0.202619.164649

GMDS now supports Business Central's standard External File Account for the file exchange between Master and Subscriber companies, alongside the existing Azure Blob Storage method. Instead of filling in Azure Blob Storage credentials directly on the GMDS setup, you can pick a File Account that you have already configured in Business Central.

What changed

• A new Import Method field on Global Master Setup lets you choose between Azure Blob Storage (the legacy method) and External File Account.
• Global Master Setup and Partner Card now show an External File Account section where you select the account and see its name and connector type.
• New promoted actions let you test the connection from inside GMDS: Show files, Upload test file, Download test file, Delete test file.

Which connectors can I use?

Any File Account connector that Business Central supports — including Azure Blob Storage, Azure File Share, and SharePoint. Credentials stay in BC's secure storage instead of being typed into GMDS fields.

Existing setups are kept as-is

When you update the app, partners and subscribers already configured with Azure Blob Storage continue to work using the legacy Azure Blob Storage path — Import Method is set to Azure Blob Storage for them automatically. There is no forced migration. When you're ready, switch a setup to External File Account at your own pace.

Note: the legacy Azure Blob Storage configuration on the Setup page will be phased out in a future release. We recommend moving new setups to External File Account.

How to use (External File Account)

1. In Business Central, configure the File Account you want GMDS to use (Search → File Accounts).
2. Open Global Master Setup (or a Partner Card).
3. Set Import Method to External File Account.
4. In the External File Account section, click to select the account you configured.
5. Use the Storage Connection actions to verify the setup: upload a test file, download it, and delete it.

Releasing a data template that contains a large record set (for example a template on the Item table with 30,000+ records) used to be very slow and could end in a timeout. The release process has been performance-optimized so these templates now release reliably, even on the very first release.

New status handling via menu

The data template status workflow has been changed to be handled via a menu. This gives teams a clear gating step to review a template before it is released for transactions. When you change the status, a new confirmation dialog is shown so you can choose the target status explicitly.

Release Duration tracking

Two new fields have been added to the data template:

• Released On — timestamp of the most recent release.
• Release Duration — how long the release took to complete.

Use these fields to monitor release performance over time, especially on templates with large record sets.

When you delete a GMDS data template, the related file log entries are now kept. Detail File Log Headers, Detail File Log Lines, and Subscriber IC File Log records remain in the system as a historical record of past synchronisations.

What changed

Previously, deleting a data template also removed every file log entry that referenced it. That destroyed the audit trail for the template's past exchanges. The cleanup now only removes the template and its direct setup — template filters, record selection, partner group update, and partner group file log.

Why this matters

File logs are your audit trail for everything exchanged between Master and Subscriber companies. Keeping them intact after a template is deleted means you can still investigate past sync activity and respond to questions about historical exchanges.

How to use

No setup change. Delete a data template as you normally would — the associated file logs will remain available for review.

When releasing BC 28.0 with BC 27.x compatibility, install and upgrade routines failed on BC 27.5. Microsoft tightened security by changing the SetSecretText procedure from public to internal, which broke the upgrade routine used to migrate legacy Azure Blob Storage setups to External File Accounts.

The legacy ConvBlobStorageSetup upgrade routine has been removed. In its place, a new upgrade routine SetImportMethod sets Import Method to Azure Blob Storage for any setup or partner that already has Blob Storage fields configured, preserving existing behaviour. The Use Original BlobStorageSetup boolean has been replaced with the new Import Method enum on SCB Global Master Setup. Install and upgrade now run cleanly on BC 27.5, with no behaviour change for existing customers.

All public procedures and methods across the codebase have been documented with XML doc comments (/// <summary>, /// <param>, /// <returns>). This makes the code self-documenting, improves IntelliSense hover information for developers, and ensures automated code review tools can provide meaningful feedback. There is no functional change.

All AL keywords throughout the codebase have been normalised from legacy UPPERCASE style (e.g. IF, BEGIN, END, SETRANGE) to the Microsoft AL standard PascalCase style (e.g. if, begin, end, SetRange). This is a cosmetic change only — AL is case-insensitive and there is no runtime impact. The change eliminates reviewer noise from mixed casing and brings the codebase fully in line with the AL Coding Standard.