SharePoint 365 SPD Workflow Dictionary default date format issue

[Tony Hignett]

Hi All,

I'm building a SharePoint Designer workflow which uses the Call HTTP Web Service action.

I have a list that contains an optional date/time field called 'Deadline'.

I've added this field to a Dictonary using the Value Current Item: Deadline.

The action updates a list item.

When the Deadline field has been set by a user, the Update request parameters contain the following JSON:

"Deadline":"2017-03-30T23:00:00.0000000Z"

When the Deadline field has not been set, I can see that the Deadline feild is returned as null using...

..._api/web/lists/getbytitle('ListName')/items

<d:Deadline m:null="true" />

But, when the REST api Update request is built, the parameters Dictionary appears to be setting a default date. It appears thus in the JSON request...

"Deadline":"0001-01-01T00:00:00.0000000"

This causes the Update request to fail...

Response Content: {"error":{"code":"-2130575155, Microsoft.SharePoint.SPFieldValueException","message":{"lang":"en-US","value":"Cannot complete this action.\u000a\u000aPlease try again."}}}

Response Code: BadRequest

Can anyone advise a way to mitigate this behaviour?

My attempts to check&react to the status of the Datetime field are unsuccessful.

Thanks,

Tony

[#2]

Ok, not Ideal but...

If Current Item: Deadline is less than or equal to 01/01/2001 00:00:00
   Build {...} Dictionary(Output to Variable: Update_Parameters)
   ** but don't include the Deadline field as a parameter **
Else
   Build {...} Dictionary(Output to Variable: Update_Parameters) 
   ** but do include the Deadline field as a parameter **

Hope this helps someone.

It's great that you can copy/paste the Build Dictionary actions within SPD.

It's a shame they empty their contents as thay are copied.

By the way...

I'm doing this as moving Document Sets with the REST api (...folder/MoveTo(newUrl))turns them into regular folders.

i.e. they lose their Content Type Id in transit.

Once, I've moved them, I update them with correct Content Type and the properties of the original.

Which reverts them back to the Documents Set I expect.

Cheers,

Tony

[#3]

@Tony Hignett I've come across this too.  Could have sworn it was working before without requiring the workaround.

As I had multiple date\time fields, I chose to remove all of them from the main dictionary.  Then I created a dictionary per date\time field and ran the REST call inside each IF statement.  Too bad there is no way to dynamically add fields to a Dictionary

[#4]

@Jason H 

Since the Dictionary object is additive, you only need to put a build statement inside each of the if conditional  statements that check whether there is a valid date value, and then run the Rest statement at the end. 

ex. 

Set tempBool to No

if Current Item: date1 is greater than > Variable: emptyDate

    Build {<add date1>} Dictionary (Output to Variable: dicRequestContentCreateItem)

     set Variable: tempBool to Yes

if Current Item: date2 is greater than > Variable: emptyDate

    Build {<add date2>} Dictionary (Output to Variable: dicRequestContentCreateItem)

    set Variable: tempBool to Yes

if Variable: tempBool equals Yes

     Call Variable: rstUrl HTTP web service with Variable: dicRequestContentCreateItem(Response Content ...