Update File Properties not working for PDF

[tsyrell]

I am working on a Library archival flow with the following basic steps:

Get file properties from source library

If selection conditions are met:

   get file metadata of source file

   get file content of source file

   create file in archive library

   update file properties in archive library

   delete file from source library

This works great for word and excel files, but for pdf's I lose all of the properties except the fact that it's a PDF.

Any help would be greatly appreciated!

Thanks, 

Tom

[ScottShearer]

@tsyrell

Can you post a screen shot of your Flow?

Scott

[tsyrell]

Here you go Scott:

[ScottShearer]

@tsyrell

This may sound silly, but can you try putting a delay of 5 minutes between the create file and update file properties actions? 

Scott

[tsyrell]

I will give it a shot and let you know how it goes.  As an FYI, my initial archive will be moving ~2500 files, so adding 5 minutes per file will be quite painful!

[ScottShearer]

@tsyrell :

Understood - I suspect that SharePoint doesn't think the file has been closed.  As a result, it won't let yu update the properties.

Scott

[tsyrell]

Running now.  Just curious, is there any way to force the file closed vs waiting?

[ScottShearer]

@tsyrell :

I am not aware of any way of avoiding this issue. I suggest reporting it as a bug.

My suggestion of 5 minutes is just a suggestion - you might experiment with a shorter delay.

As I said above, I believe that the create file action, in some cases, is not closing the file properly and it takes a while for SharePoint to automatically close it.  I have seen similar issues when an Excel file has been opened and edited - the file does not appear to be closed properly.

For purposes of your migration, consider the following:

Have one Flow that handles Office documents -filter out everything else

Have one Flow with the delay that only runs on .pdf files and other types where you may be having this issue.

If I have answered your question, please mark your post as solved.

Scott

[tsyrell]

Unfortunately, that doesn't seem to have resolved the issue.  The first couple of PDF's that have moved over have not carried over their original properties.  Any other suggestions?

Tom

[ScottShearer]

Are any of the columns that you are setting getting populated?

Scott

[tsyrell · Accepted solution]

Scott,

Sorry, tied up in meetings.  Some of the fields are getting updated: Release Status, Release Type, Request Numbers. Others aren't: Content Type is defaulting, not carrying over from source document (only for PDF's), and Component(s) Impacted is not working at all for any doc type.  This field is defined as a a choice field allowing multiple selections.  I need to resolve this issue as well.

Thanks again for your help.

Tom

[tsyrell]

Hi Scott, 

I'm still running into some issues with the PDF, as well as some other interesting quirks that I need to resolve.  I created 3 new fields in the archive library: LCreateBy, LModBy and LModDate where I can store the original values from the source library as those would get update on the Create File.  I also created ArchiveDate to capture the actual date the file was archived.  They were previously working fine for non-PDF files, but as I mentioned in my last post, the multiple choice field Component(s) Impacted was not moving correctly to the archived file.  

I did some research and was trying a few things to no avail, but part of the process was creating a new string field (Dummy) in the archive library to try to concatenate the values together.  When I did created the field, (see first example of the update file properties), the Component(s) Impacted field now populated correctly, but the LCreateBy, LModBy and LModDate no longer populated (see first example of sharepoint library red outlined sections).  

When I don't set that field to anything (see second example of the update file properties), then I'm back to where I was with the Component(s) Impacted field not populated correctly for all documents and the Content Type for PDF's, but everything else is (see second example of sharepoint library outlined in red).

Any help is greatly appreciated!

Tom

[Jay-Encodian]

Hi Tom,

I've had a quick read through... and a few quick comments for thought;

can you verify the configuration of the date time columns your trying to map are the same, addittionaly is the 'Components' field a site column or at least centrally provisioned in someway, either via the CT hub or using a PnP based prov solution.

I haven't verified but I'd epxect the choice fields need to be identical as the data stored under the hood uses ID's... if you've manually setup the column in both places there could be differences causing your issue.

HTH

Jay

[tsyrell]

Hi Jay, 

I actually think I'm all set.  For the PDF issue, I changed it from a Get File Metadata - Get File Content - Create File - Update File Properties to a Copy File - Update File Properties, and that seemed to work.  

For the non-PDF files, I'm not exactly sure what I changed (I'm new to flow), but I managed to get all of the new fields updated correctly, so I'm good there.

For both, with the multi-choice field, I stumbled across this and it worked.  The first pic shows how I had it set.  If I cleared out the value and clicked on the icon to the right (second pic), that copied all of the choice values selected on the source file over to the target file.  

At this point, I think I can mark this one solved.

Thanks for your input.  And thanks to Scott as well.

Tom