Forum Discussion
Dynamics 365 connector not including column RegardingObjectTypeCode
I am trying to collect data from Dynamics 365 and the table activitypointer. This has a column called RegardingObjectId and a column called RegardingObjectTypeCode that explains what tybe fo object RegardingObjectId is for (account, contact, etc.)
When collecting data with the Dynamics 365 connector I do not get any data from RegardingObjectTypeCode. I can however add a filter for certain types as shown in the screenshot below. This wil only include one of the regardingobjecttypecodes. But it is not a feasible solution to duplicate my logic and add filters in this way. Is this a bug in the connector for the linked service? We are considering trying to use the Azure Synapse Link to write data directly into our data lake, but don't currently now if this issue will be there as well.
Hi HelgeG ,
Thanks for sharing the screenshot. Based on the your query, try below recommendation steps :
- If you're not seeing the RegardingObjectTypeCode in your query results, it might be due to limitations in how the connector is designed some connectors don’t expose certain fields by default, especially if they're not directly part of the main entity.
- As you noted, applying filters for specific RegardingObjectTypeCode values leads to repetitive logic, which isn’t an efficient or scalable solution. This is a common challenge when working with connectors or APIs that don’t fully expose all required metadata fields.
- If you're considering Azure Synapse Link, it's worth testing first it writes data to your data lake in near real-time and usually includes all fields, including RegardingObjectTypeCode, which the connector currently misses. It could solve your issue without needing complex workarounds.
If this post was helpful, please consider marking Accept as solution to assist other members in finding it more easily.
If you continue to face issues, feel free to reach out to us for further assistance!
11 Replies
Hi HelgeG ,
Thanks for sharing the screenshot. Based on the your query, try below recommendation steps :
- If you're not seeing the RegardingObjectTypeCode in your query results, it might be due to limitations in how the connector is designed some connectors don’t expose certain fields by default, especially if they're not directly part of the main entity.
- As you noted, applying filters for specific RegardingObjectTypeCode values leads to repetitive logic, which isn’t an efficient or scalable solution. This is a common challenge when working with connectors or APIs that don’t fully expose all required metadata fields.
- If you're considering Azure Synapse Link, it's worth testing first it writes data to your data lake in near real-time and usually includes all fields, including RegardingObjectTypeCode, which the connector currently misses. It could solve your issue without needing complex workarounds.
If this post was helpful, please consider marking Accept as solution to assist other members in finding it more easily.
If you continue to face issues, feel free to reach out to us for further assistance!
I can confirm now that Azure Synapse Link is writing data for RegardingObjectTypeCode. Haven't tested other similar columns, but this seems to be the solution.
thanks for your reply. We are looking into Azure Synapse Link as an alternative. Will update when I know if this resolves the problem. But this is a limitation that should be documentet for the connector I think. Will update when we have the permissions in place to test Azure Synapse Link!
Hi HelgeG ,
Thank you for the update,Please do keep us posted once you’ve had a chance to test with the appropriate permissions. We’d appreciate hearing if Synapse Link resolves the problem or if further assistance is needed.Hi HelgeG ,
we wanted to follow up regarding your testing of Azure Synapse Link. Have you had a chance to set up the necessary permissions and conduct your tests?We’re eager to hear if Synapse Link has resolved the issue you were facing or if you require any further assistance from our side.
Thank you, and we look forward to your update!
Hi
We are also using azure synapse link for D365 appointments table, the column regardingobjecttypecode is in the csv file that goes to the datalake, but there is no value in it. If I create an appointment record with a regarding contact, the value should be 2, but it's null.
Since you cannot tick individual columns in Azure Synapse Link, only tables, it's strange that the column is there, but not the value. Is this a bug in Azure Synapse Link?
The same thing happens in other tables that have such a related field, like activitypointer, task, email, ...
Kind Regards,
Vera
That is strange, and makes me less hopeful that Synapse Link can be a solution for us as well. Have you been able to find another workaround for this problem?
No, I haven't found a workaround.
I want to use it to create PBI reports where this regardingobjecttypecode = 2, to filter for contacts. Only way to do that now is to write a query with an inner join to the contacts entity, based on regardingobjectid, that way only ids with a link to an existing contact will be in the result.
But it's extra code and rather stupid to link to an extra table only because the value in the field that is created for that filtering (regardingobjecttypecode), does not contain data although it should.
