Mapping Standard Fields: BC Salesperson Code (with TableRelation) vs. CRM Account OwnerId

(6) Share

Report

Posted on by MarcIbanez

We are setting up the standard synchronization between Business Central and Dataverse for the Customer table. Our goal is to map the standard Salesperson Code field in BC to the OwnerId (Owner) field of the Account in CRM.

We have noticed that it is not possible to configure this mapping through the standard UI on the "Integration Field Mapping" page. The system seems to prevent this for two reasons:

It does not allow us to select fields for mapping that have a TableRelation (like Salesperson Code).
It also does not appear to permit direct mapping to destination fields that are GUID types (like OwnerId).

However, we have confirmed that we CAN achieve our goal if we create the mapping via AL code in a codeunit, using the InsertIntegrationFieldMapping function.

Our query is to confirm if this is the expected behavior. Is the standard UI configuration designed to block these complex mappings, and is using AL code the only supported and correct way to synchronize a field with a TableRelation from BC to a GUID field in CRM?

Thank you in advance for your clarification.

Best regards,

Categories:

Dynamics 365 Business Central

I have the same question (0)

All responses (6)

Answers (2)

Sort by

Verified answer

YUN ZHU 100,212 Super User 2026 Season 1 on at

Like (4)

Report
Copy link

Link copied!

The standard connection settings have many limitations, and hopefully the information below will give you some hints.

Dynamics 365 Business Central Blog Series: Integrate with Microsoft Dataverse

https://yzhums.com/63916/

Thanks.

ZHU

2 people found this reply helpful.

Was this reply helpful? Yes No
Verified answer

Pallavi Phade 5,510 Super User 2026 Season 1 on at

Like (4)

Report
Copy link

Link copied!

Namaste MarcIbanez ,

This seems to be limitation . You still can verify in below link

https://learn.microsoft.com/en-us/dynamics365/business-central/admin-how-to-modify-table-mappings-for-synchronization?source=recommendations

You need to customize AL .

Would recommend to raise ticket in MS

Regards

Pallavi Phade

2 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

Sahan Hasitha 2,683 on at

Like (6)

Report
Copy link

Link copied!

hi

what you are seeing is expected behavior in Business Central–Dataverse synchronization. The standard Integration Field Mapping UI is limited to simple 1:1 mappings of compatible field types. Fields with a TableRelation in BC (like Salesperson Code) and destination fields that are GUIDs in Dataverse (like OwnerId) are intentionally blocked in the UI, since they require transformation logic. The supported approach in these cases is exactly what you’ve done: define the mapping programmatically in AL (e.g. via InsertIntegrationFieldMapping), where you can implement the conversion between BC keys and Dataverse GUIDs. In short, the UI is designed for simple mappings only, while AL code is the correct and supported way to handle complex mappings such as BC relation fields → CRM Owner fields.

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

MarcIbanez 32 on at

Like (3)

Report
Copy link

Link copied!
The final decision was to implement Option 2 to ensure long-term stability, control, and compatibility.

Option 1: Direct Mapping via Code (The Simple Way)

This consists of using the InsertIntegrationFieldMapping function in AL code to force a direct mapping between the Salesperson Code field in Business Central and the OwnerId in CRM. The data transformation is delegated directly to the synchronization engine.

Pros:

Faster implementation.

Fewer objects and lines of code.

Cons:

Discouraged by Microsoft support and MVPs.

Option 2: Indirect Mapping via Code (The Robust and Recommended Way)

This is a multi-step architecture that decouples the data's arrival from its processing:

In CRM: The OwnerId is duplicated to a text field, which is kept updated by a flow (Power Automate).

In Business Central: A proxy table and a duplicate field are created on the customer card. The standard synchronization simply moves the GUID from the CRM text field to the proxy table field.

Logic in BC: Event Subscribers are used, which trigger after the synchronization. They read the GUID from the proxy table, execute the transformation logic, and update the final Salesperson Code field.

Pros:

Recommended by Microsoft support and MVPs.

Robust and safe: a failure in the transformation does not stop the main synchronization.

Full control over the logic and error handling.

Stable against future BC updates.

Cons:

Requires more initial development (more objects and code).

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

Nimsara Jayathilaka. 5,001 Super User 2026 Season 1 on at

Like (6)

Report
Copy link

Link copied!

Hi

Yes, this is expected behavior. The standard UI for Integration Field Mapping intentionally blocks mappings from TableRelation fields in BC to GUID fields in Dataverse. To achieve this, the supported approach is exactly what you did — implement the mapping through AL code using InsertIntegrationFieldMapping.

For Refer : https://yzhums.com/63916/

Thanks

Nimsara

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

Rishabh Kanaskar 6,225 Super User 2026 Season 1 on at

Like (5)

Report
Copy link

Link copied!

Hi,

Yes, this is expected behavior. The standard Integration Field Mapping page only supports simple field mappings (no TableRelation lookups or GUID conversions).
For mapping fields like Salesperson Code > OwnerId, using AL code with InsertIntegrationFieldMapping (and handling the lookup/translation in code) is the correct and supported approach.

The UI intentionally restricts these mappings to avoid runtime issues.

Thanks

Rishabh

Was this reply helpful? Yes No