cancel
Showing results for 
Search instead for 
Did you mean: 

Allow Setting null value to the lookup field in Common Data Service (current environment) connector

One of the feature gaps between Common Data Service connector and Common Data Service (current environment) connector is the ability to set the null value to the lookup field.

 

When we set the null value to the lookup field in Common Data Service (current environment) connector, the flow fails with the following error.

 

 

An error occurred while validating input parameters: Microsoft.OData.ODataException: The 'odata.bind' instance or property annotation has a null value. In OData, the 'odata.bind' instance or property annotation must have a non-null string value.

 

 

 

It is important when we want to clear multiple lookup fields in one API call (without multiple Unrelate records actions), or the most common issue for me is passing the GUID from another step which is an optional lookup field (so that the value may/may not be null)

If the lookup field is polymorphic for both source and target records, it will be good if we can check the entity type in the expression and fill null/the target record OData ID accordingly into the right field.

 

One of the examples is Setting the Primary Contact in the screenshot below with the GUID value of "Primary Contact (Value)" which can be empty from the source data. Common Data Service (current environment) connector cannot handle this kind of scenario and it will be great if we can use a null check expression for that case.

 

 

if(empty(triggerOutputs()?['body/_primarycontactid_value']), null, triggerOutputs()?['body/_primarycontactid_value'])

 

 

Flow Value Set.png

 

CC: @Audrie-MSFT 

Status: New
Comments
Regular Visitor

This is a bug not a feature and should be fixed as per normal code bug management. Please advise.

Advocate I

@WhiteySenior :Exactly

@LinnZawWin :  even with the expression you gave if it supports , still it is very unfair for a business administrator and not a true developer for them to write all these if and else conditions when the old connector used to support a direct GUID , without all this fuss. Hope they bring back the previous implementation and scrap this good-for-nothing behavior.

Frequent Visitor

Agreed.  This bug makes this connector totally useless for us

Regular Visitor

Agreed, this makes it also very hard for us to use the (current) connector.

Regular Visitor

@LinnZawWin : I totally agree the new approach a step backwards from the original connector.

 

They declare the original connector "decommissioned" and offer a more difficult and broken offering. Seems quality testing takes second shelf to marketing bullet points. Would like to have an understanding of the thinking here.

Advocate V

@pavansarma_2301 

I totally agree that the way of setting the lookup values in the CDS (CE) connector itself is harder for citizen developers to find out the plural version of the entity schema name.

I am just wondering how would an average citizen developer know where to find the WebAPI and plural version of the entity schema name (aka EntitySetName)

Regular Visitor

It has been 5 months now and this idea is still not under investigation. Please Microsoft, fix this!

New Member
Regular Visitor

Hi @manishchouhan,

Not sure how you could possibly use this as a solution if you have many lookups on a single record to set. 

Thanks but MS really needs a permanent solution.

 

Advocate V

@manishchouhan  thanks for the suggestion.

But the most common issue for me is passing the GUID from another step which is an optional lookup field (so that the value may/may not be null)

In that case, I cannot just directly bind the reference lookup value from the Dynamic content to the field because it will cause an error when the value is null. I have to add another update step after condition step to check if the value is not equal to null. (and imagine doing that for multiple lookup fields) 😫