As we are close to another major release, I will try to share some insights into upcoming changes. I do not want to repeat other authors and blog posts, as I think there are already enough posts about the most visible changes.
Instead, I will describe the changes I made through the Business Central contribution program. As an author, I may be able to provide a bit more details or my thoughts on why/how I implemented the change.
My plan is to split into three blog posts over the next two weeks:
- Changes related to CRM integration (THIS BLOG POST)
- Other changes in BC processes and functions/for consultants and users
- Changes in the background logic/for developers
Synchronize “CRM Notes” with the correct mapping
“CRM Notes” uses the standard integration mapping between Sales Orders and CRM Sales Orders. However, the filter for this mapping used only the filter for the BC table, not both.
This caused issues when you added a custom integration for the Sales Header with another table.
The contribution is an updated filter that always uses both tables to find the proper mapping.
Allow “Coupled to Dataverse” with affixes
The field “Coupled to Dataverse” is used by users to identify records in Business Central coupled to D365 Sales (CE) records. However, it is also used by a few background processes that need to know which field should be used.
For this reason, whenever you create a custom integration for a custom table, add this field with the exact name “Coupled to Dataverse“. However, if you add an integration for an existing OOTB table, you can’t add such a field without affix (suffix or prefix) without risking future issues if Microsoft decides to add the field to the OOTB solution (for example, now for Field Service integration).
The contribution here is the code that searches for the field “*Coupled to Dataverse*” including affixes if the field with the exact name is not found.
Use CRM TableID to find CRM TableName
The ability to translate CRM Table ID to CRM Table Name (or to get CRM Table Name from BC Table ID) is required to create correct hyperlinks. Users in BC use these hyperlinks to open coupled records.
The problem with the current design is that the table used to determine the correct entity name is the Business Central table, not the target CRM Table. This is not a problem as long as there is only one CRM table used for synchronization with one BC table. However, if you have multiple CRM tables synchronized with one BC table (using different filters applied to BC integration table mapping), the hyperlinks will not be correct.
The contribution changed the logic of how the CRM table name is determined. Instead of using the BC table, the system tries to use the CRM table (where possible) instead. The CRM Table will always return the correct table name as these two values (Table ID and Name) are unique. System still needs to support also the original BC Table ID process as there are some mappings that do not have CRM table defined for the mapping (for example Unit of Measures, where the whole integration is quite a magic and different from other integrations).
