Updating Sharepoint list date column to blank

[AnnonymousUser]

Hi everyone,

I'm trying to update a date value in sharepoint list to a blank/null value and can't seem to do it.

I'm currently using null expression but as you can see in the screenshots it's not working

Here is the error:

Thanks in advance for your help!

[ManishSolanki]

Hi @AnnonymousUser 

Pls verify if field_5 is the internal name of the "Return Date". The error might occur for some other datetime field which doesn't handle empty value.

If this helps & solves your problem, please remember to give a 👍 and accept my solution as it will help others in the future.

[AnnonymousUser]

Hi @ManishSolanki ,

field_5 is actually the internal name of Return Date and it handle empty values. I have no problem clearing it in PowerApps or directly on the list but PowerAutomate is giving me trouble.

[MarkBandR]

Hi @AnnonymousUser ,

I just duplicated what you are seeing as I have used the method you are trying to do in the past to clear out a DateTime field.

This seems to be an issue with the new UI. CoPilot is causing the "@{null}" to be treated as a string. If you switch out of the "New Designer" (at the top right), by flipping the toggle. You can edit the "Update item" action. When you put in null it will appear as "undefined" or "Null":

Editing it with the old Designer seems to make things work correctly. After you save the Flow and test it, you can switch back to the New UI. The Flow should continue to work as expected.

I'm not sure who this issue should be reported to as it seems to be a bug in the new CoPilot UI for the "Update item" Action for SharePoint.

If I've answered your question or solved your problem, please mark this question as answered. This helps others who have the same question find a solution quickly via the forum search. If you liked my response, please consider giving it a thumbs up.

Thanks.

-Mark

[Chriddle]

I just checked this. It worked well in the classic designer.

But after switching to the new designer I get the same error 🤣😂

[Chriddle]

And there is a difference in the action's JSON:

Classic designer: "item/Now":"@null"

New designer: "item/Now": "@{null}"

[Chriddle]

If you insert null like this in the new designer

then after saving it looks like this

and also in the Code View it looks fine:

and the flow runs without error.

[Thoman]

@Chriddle THANK YOU! This was driving me nuts and was about to go down the path of doing a SharePoint HTTP Request method which is a pain if you are using environment variables, solutions and deployment pipelines.

[MarkBandR]

Hi @Thoman ,

I don't mean to jump in here but can you talk about the following more:

go down the path of doing a SharePoint HTTP Request method which is a pain if you are using environment variables, solutions and deployment pipelines

I am using the SharePoint HTTP Request method in several flows with environment variables in a solution. I haven't setup my deployment pipelines yet. I was wonder what I should keep an eye out for. I am using the ValidateUpdateListItem REST call to properly set Hyperlink fields with a URL and Description. I build the Uri call as:

/_api/web/lists(guid'<Insert SP List Env Var Here>')/items(<ID>)/validateUpdateListItem

where the SP List is just the standard Environmental Variable to a SharePoint List. It resolves to the GUID of the List. I use that as a method of getting the list instead of GetByTitle.

Thanks

-Mark

[Thoman]

The annoying thing is going to be the number of variables you will have to keep for the same object. MS will give you variable sets for SharePoint Sites, Document Libraries and Lists. But they are stored differently than how an HTTPS request needs them. So you will also have to keep the site URL, List\Library Name and\or GUID in a string environment variable. Just more things to track and then always have to update every time you publish to the next environment. It's not the end of the world.... just a pain if you want to quickly publish up the changes. This is because you have to delete the variable before publishing to the next environment else it will keep your existing values. This video is helpful to understand how to handle it. https://www.youtube.com/watch?v=BFGcXSAgawM

It through me for a loop because I had published what I thought were defaults for one environment only but after publishing up, never got prompted to change them before deploying in the next environment. MS is still making UI changes here and it's getting better... just not perfect yet.