Daniel Göhler prisma informatik GmbH

Currently, Business Central provides the capability to attach documents to sales documents, which significantly enhances document management and workflow efficiency. However, this functionality is missing for reminders and issued reminders. To ensure consistent documentation and streamlined processes, we propose adding the ability to attach relevant documents directly to reminders and issued reminders.

It would be great if Error Message Management were added to the Whse.-Post Shipment codeunit, ensuring a consistent look and feel with sales order posting.

In codeunit 454, "Job Queue - Send Notification," Record Links are created every time an error occurs. However, these links are not displayed in the Business Central web client. The last version where they were useful was Business Central 14, where they appeared in the Role Center of the Windows client. Even worse, there is no retention policy for cleaning up these Record Links, leading to potential clutter over time.

Recently, the Job Queue Log Entry now receives an End Date even when the status is "In Progress" or "Error." The retention policy filters entries based on this field. However, many of our customers have a large number of Job Queue Log Entries with a starting date in August 2024 or earlier, where the End Date remains empty. As a result, these entries are not deleted by the retention policy.

It can be challenging to keep track of changes, bug fixes, and new features introduced in various versions of Business Central, especially given the different locations where updates are announced. To address this issue and improve user experience, I propose the addition of a comprehensive Change Log feature within Business Central. This feature would function similarly to the existing "Feature Management" page but with a greater focus on detailed change tracking and versioning.

Proposed Change Log Features:

1. Detailed List of Changes:

• The Change Log would include a complete list of modifications (e.g., bug fixes, new features, and improvements) across all versions.
• Each entry would specify:
• Change Type: Bugfix or Feature.
• Description: A brief summary of the change.
• Version Added: The specific version in which the change was introduced (e.g., Business Central 25.0, 25.1, 25.2).

2. Integrated Links for More Information:

• Each entry would include a link to detailed release notes or documentation, where available, for users who want to dive deeper into the specifics of a change.

3. Detailed Descriptions and Setup Guidance:

• When an entry is selected, it would display a detailed description of the change (a few sentences).
• If applicable, it would include a **link to related setup instructions** to help users implement or configure the new feature or fix.

4. Centralized and Searchable Interface:

• The Change Log would serve as a single source of truth for tracking all updates, consolidating information from:
• https://aka.ms/BCLastMinorUpdate
• https://releaseplans.microsoft.com/en-US/?app=Business+Central
• https://learn.microsoft.com/en-us/dynamics365/release-plan/2025wave1/smb/dynamics365-business-central/planned-features
• Users could search and filter by version, change type, or keyword to quickly find relevant updates.

5. Insider Sandbox Tracking:

• The Change Log would also include updates specific to Insider Sandboxes, allowing users to track changes tested in preview environments.
• This would clarify whether a change has been officially added to the production version or remains in preview.

Benefits of the Change Log Feature:

1. Improved Transparency:

• Users can easily identify what has been added, changed, or fixed in specific versions.
• Consolidates fragmented information into one accessible location.

2. Enhanced User Experience:

• Quick access to release notes, documentation, and setup guides reduces frustration and confusion.
• Helps users and administrators understand changes without needing to search through multiple external resources.

3. Streamlined Version Management:

• Provides a clear overview of features and fixes by version, making it easier to plan upgrades or evaluate the impact of changes on business processes.

4. Better Support for Developers and Administrators:

• Developers can quickly check whether a bug has been fixed or a feature has been added in the latest version.
• Administrators can plan system updates with confidence, knowing what changes to expect.

Example Interface:

The Change Log page could be organized as follows:

• Column Headings:
• Change Type (Feature/Bugfix)
• Description
• Version Added
• Detailed Link
• Setup Guide Link (if applicable)

• Detail Pane:
• Clicking on a change displays a pane with a more detailed explanation and setup instructions.

Could you please ensure that the announced file drop zone feature (https://learn.microsoft.com/en-us/dynamics365/release-plan/2023wave2/smb/dynamics365-business-central/handle-multiple-file-uploads-file-drop-zones) is available? Currently, it is not working as expected. You can find a screenshot of it not working and discussion on the issue here: https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=3245535768633344

During his session “What’s Next: AL-Go for GitHub” (BC 2025 Wave 1) https://www.youtube.com/watch?v=6B6F38AswE8 Freddy Kristiansen has announced the end of BCContainerHelper.

The functionalities currently used by AL-Go for GitHub will need to be migrated into separate PowerShell modules. According to Freddy, this transition is expected to take another two to three years.

BCContainerHelper is essential for local Business Central development environments. Please continue to support this solution going forward.

Unbound actions in AL (via OData V4) provide a flexible way to expose logic not tied to specific entities. However, in the current Business Central development model, they are not treated as first-class citizens:

• No dedicated codeunit type to distinguish them from standard business logic.
• Manual registration is required via the Web Services page.
• No metadata, versioning, or built-in routing structure like API Pages offer.
• No way to clearly define and govern reusable service endpoints.

This makes the experience inconsistent and more difficult for developers building modern integrations or replacing SOAP-based services.

More: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-creating-and-interacting-with-odatav4-unbound-action

We propose introducing a dedicated API codeunit subtype in AL to give unbound actions first-class citizen status in Business Central development.

codeunit 50110 "CustomerApiOperations"

{

  Subtype = API;

  APIPublisher = 'mycompany';

  APIGroup = 'customerOps';

  APIVersion = 'v2.0';

  procedure Ping(input: Integer): Integer

  begin

    exit(-input);

  end;

  procedure NotifyCustomer(inputJson: Text): Boolean

  var

    payload: JsonObject;

    customerNo: Code[20];

  begin

    payload.ReadFrom(inputJson);

    if payload.Get('customerNo', customerNo) then

      Message('Customer %1 has been notified.', customerNo);

    exit(true);

  end;

}

Automatically exposed as:

POST /api/mycompany/customerOps/v2.0/Ping

POST /api/mycompany/customerOps/v2.0/NotifyCustomer

Making unbound actions first-class citizens in AL would:

• Encourage modern, function-based integration patterns (microservices, headless scenarios, automation).
• Simplify discovery, documentation (OpenAPI), and versioning.
• Align AL development more closely with modern API-first standards.
• Make AL more expressive and efficient for scenarios where no table binding is needed.

I went through a long and confusing support case (#2503261420003356) trying to debug web service requests in a Business Central cloud sandbox using the Attach and Debug Next functionality. Neither I nor Microsoft Support could initially identify why the debugger wasn't triggering.

Eventually—thanks to the Dynamics 365 Yammer community (https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=3278156612993024)—I learned that you must explicitly specify the userId of the App Registration (Field User ID without brackets from the Microsoft Entra Application card) in the launch.json when debugging web service calls on cloud sandboxes. This critical requirement is not mentioned in the current documentation.

What's Missing / Needs Clarification

The documentation for the Attach and Debug Next feature does not mention that the userId is mandatory when attaching to web service requests in cloud sandboxes. https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-attach-debug-next#example-attach-to-an-online-sandbox-web-services-session

There's no warning or guidance from the AL Language extension when trying to debug a session that silently fails due to missing userId.

Suggested Improvements

1. Update the official documentation to state clearly:

• When attaching to web service requests on a cloud sandbox, userId must be set to the Microsoft Entra App Registration's User ID if the session is initiated by an app (e.g., via OAuth).
• Provide an example that reflects this scenario.

2. Enhance the AL Language extension to:

• Warn or notify the developer when attempting to attach to a web service client in a cloud sandbox without a userId, especially if using OAuth.
• Optionally suggest the App Registration User ID from the active app.json or connected identity.

Why This Matters

This requirement is obscure but essential. The current lack of documentation and tooling support causes:

• Wasted hours debugging sessions that never break,
• Frustration during development and testing of integrations,
• Reliance on external community sources to solve what should be a well-documented behavior.

In codeunit 5343 "CRM Sales Order to Sales Order", the method ApplySalesOrderDiscounts currently displays a confirm message whenever the CRM Sales Order Header contains a Discount Amount or Discount %.

The message is as follows:

"There is a discount on the %2 sales order, which will be overwritten by %1 settings. You will have the possibility to update the discounts directly on the sales order, after it is created. Do you want to continue?"

This message appears regardless of whether discounts are actually configured in Business Central. Additionally, if the user selects "No", the Sales Order creation process fails with an unclear error message (Error('')), making the process confusing and frustrating for users.

Suggested Improvement:

Before displaying the confirm message, the logic should:

1. Check the G/L Setup and
2. Evaluate per-customer invoice discount settings.

If neither of these are configured in Business Central, the confirmation message should not be shown at all, as there is no conflicting logic that would override the CRM discount values.

This would improve the user experience by:

• Avoiding unnecessary and misleading prompts.
• Ensuring discounts from the CRM Sales Order are transferred correctly to the Business Central Sales Order without unnecessary intervention.
• Providing a smoother integration flow between CRM and Business Central.

Expected Behavior:

• If no conflicting discount settings are configured in Business Central, allow the CRM discount values to transfer without showing the confirmation dialog.
• If a conflict exists, continue to show the confirmation with a clearer explanation and ensure the error handling is more informative if the user declines.

Screenshot can be found here: https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=3282868823990272