Dynamics 365 Business Central

Currently, Business Central allows partners and customers to opt out of app updates for minor version upgrades, but this flexibility is not available for major version upgrades. This limitation creates significant challenges for customers operating in highly regulated industries, where every update must undergo rigorous testing and validation before deployment.

Problem:

During the transition from a test environment to production on a new major version, new app versions may be released in the interim. This results in discrepancies between the tested environment and the production environment, potentially invalidating the testing process and causing compliance issues.

Proposed Solution:

To better support customers with strict regulatory requirements, we propose one of the following enhancements:

1. Allow opt-out of app updates during major version upgrades, similar to the current functionality for minor versions.
2. Introduce a version-locking mechanism, where administrators can specify the exact app versions to be installed during a major upgrade. This would ensure consistency between test and production environments.

Benefits:

• Ensures compliance with regulatory testing requirements.
• Reduces risk of unexpected behaviour in production.
• Improves confidence in Business Central as a platform for regulated industries.

Dear Microsoft Dynamics Team,

I would like to propose a feature enhancement for Dynamics 365 Business Central that would greatly benefit organizations using the Service Management module.

Feature Request:

Enable Item Charge Assignment functionality within the Service module. Currently, item charges (such as freight, handling, or additional costs) can be assigned in sales and purchase documents, but this capability is not available for service orders.

Business Justification:

Service operations often involve additional costs that need to be allocated accurately to items or services for proper cost tracking and profitability analysis. Having item charge assignment in service documents would:

• Improve financial accuracy for service transactions.
• Ensure consistent cost allocation across all modules.
• Reduce manual workarounds and customizations.

This feature would align the Service module with existing capabilities in Sales and Purchase processes, providing a more integrated and efficient experience for customers.

Thank you for considering this suggestion. Please let me know if further details or use cases are required.

In almost all projects, we have the requirement that the shipment no must be specified on the posted sales invoices. When the sales invoice lines are created in BC using the function "Get Shipment Lines", the corresponding shipment no is inserted as a comment line. 

If the Post function is called up in a sales order with the option „Invoice“ or „Ship and Invoice“, no shipment no determination takes place. Here it would be desirable if the shipment no is also inserted as a comment line above the sales invoice lines.

We would like the same result, as we use the function "Get shipment lines"

Summary

Currently, the Dynamics 365 Business Central Admin Center only offers a single, overarching administrator role and permission set. We propose introducing granular roles and API permissions to allow for safer, more specialized management of environments, apps, and settings.

Reasoning & Security Context (Principle of Least Privilege)

The current all-or-nothing security model forces organizations to violate the Principle of Least Privilege (PoLP). Because there is only one blanket admin permission, any user or service principal that needs to perform a single, routine task—such as updating an app or modifying a setting—must be granted full administrative access.

This creates a significant security and operational risk. For example, a service principal designed exclusively to automate app updates currently holds the power to delete, copy, or rename entire environments. By introducing granular roles, organizations can strictly limit service principals and administrative users to only the permissions necessary for their specific job functions, greatly reducing the blast radius of compromised credentials or accidental misconfigurations.

Proposed Roles

1. Dynamics 365 Business Central Administrator

• Permissions: Full access.
• Capabilities: Create, Copy, Restore, Delete, Rename Environments, and all other administrative tasks.

1. Dynamics 365 Business Central Environment Contributor

• Permissions: Environment-level management without destructive capabilities.
• Capabilities: Change environment states (start, stop, restart, manage sessions), perform Database Exports, create Support Requests, change environment settings (telemetry connection strings, update windows, application versions), and manage apps.
• Restrictions: Cannot Create, Copy, Restore, Delete, or Rename environments.

1. Dynamics 365 Business Central App Contributor

• Permissions: App lifecycle management only.
• Capabilities: Install, update, and manage apps.
• Restrictions: Cannot change environment states or environment-level settings.

1. Dynamics 365 Business Central Support Contributor

• Permissions: Support and diagnostics.
• Capabilities: Create Support Requests, perform Database Exports.

1. Dynamics 365 Business Central Notification Recipient Administrator

• Permissions: Administrative communications.
• Capabilities: Manage notification recipients (could alternatively be rolled into the main admin role).

1. Dynamics 365 Business Central Entra Application Administrator

• Permissions: Identity and access integration.
• Capabilities: Manage and authorize Entra apps within the BC Admin Center.

1. Dynamics 365 Business Central Reader

• Permissions: Global read-only access.
• Capabilities: Read all settings, environments, and logs.
• Restrictions: No edit/write permissions whatsoever.

Proposed API Permissions / Scopes

To support these roles programmatically (especially for service principals and CI/CD pipelines), the API permission scopes should be expanded as follows:

• https://dynamics.microsoft.com/business-central/overview/AdminCenter.ReadWrite.All (Currently exists)
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.Read.All
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.ReadWrite.Environments
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.Read.Environments
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.ReadWrite.Apps
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.Read.Apps
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.ReadWrite.EntraApplications
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.Read.EntraApplications
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.ReadWrite.NotificationRecipients
• https://dynamics.microsoft.com/business-central/overview/AdminCenter.Read.NotificationRecipients

BC-Tables of Table Type "CRM"/*CDS* Still Contain Option Fields

Business Central (BC) offers a standard connector to CRM. The core of this connector is the representation of Dataverse entities in BC as tables with "TableType = CRM". These tables contain the existing fields of the CRM entity with appropriate field types.

The main issue arises with how AL handles the development of CRM fields of type "Picklist". AL offers two approaches for this:

- Option: 

- Enum: 

While Enums have replaced Options in many cases in AL due to various reasons, Option fields are still prevalent for Picklist fields, particularly in the CRM tables of BC. This includes tables such as:

- CRM Contact

- CRM Account

- CRM Salesorder, and many others

One main characteristic of Option fields contribute to an unnecessarily high effort in developing customizations for customers regarding the CRM Connector of BC:

Non-extendability: Options cannot be extended. If a customer customizes Picklist values in CRM (e.g., adding or replacing option values), it's not possible to add these values to existing Option fields in BC. This necessitates the creation of new fields in the customer app, including extensions of the basic logic (e.g., table mappings) of the CRM connector in BC.

Therefore, the idea/request would be to either delete the fields of type “Option” in BC tables of “TableType=CRM” in the base app (or at least mark them as obsolete) and exlcude them in the standard connector logic if they are not needed for core functionality.

This would enable developers to create their own Enum fields when synchronization purposes are required without having to replace existing logic of the base app.

Alternatively, the Option fields in the base app could be replaced directly with Enum Fields, as has been done in some cases already. This is particularly crucial in Tables of TableType=CRM, as it's highly likely that customers will add values to Picklist fields in CRM.

On the job task and activity task record, the "Queue Item Details" button appears on the top banner.

However, this functionality, does not exist on the Job Record. In some instances, Queues are used to describe changes to be applied on the Job Record, but the user is forced to open multiple tabs to view the Queue Item Details and Job Record. Including the button for "Queue Item Details" on the job record will create efficiency for our Admin Colleagues as they will not have to leave the Job record to update the 'Queue Item Details' and can modify them from within the Job itself.

When selecting field 140 Picture and downloading the Template in Word it is shown only the GuidID, and not the Picture itself.

On version 22.1 NL with Cronus Database: -> we are opening Word document -> Edit related entries.

The next step is to expand Number of Selected Fields

From the initial expansion you will see Filed 140 which will disappear on the next opening.

The issue is that when selecting field 140 Picture and downloading the Template in Word it is shown only the GuidID, and not the Picture itself.

We are looking forward to the improvement of this behavior in one of our future releases.

I believe it would be a great improvement if we enable server side printing (Schedule A Report feature) in a SaaS deployment, as this is currently a limitation of our product, and our partners have expressed their opinions for the implementation for this subject.

PRINTING options using 16.x Web Client - Dynamics 365 Business Central Forum Community Forum