Forum Discussion

Sean Kuchle's avatar
Sean Kuchle
Brass Contributor
Sep 01, 2020

Power Automate Sharepoint file Copy not keeping the created by

Like many I'm trying to move my SharePoint Designer Workflows to Power Automate. I ran into a problem with copying a file from one SharePoint library to another. I use 2 libraries, one where the users can add a file, then the file is copied to an archive library where they can not make any changes. Currently I'm using a workflow in impersonation mode where when a file is changed it copies the file to the archive library overwriting what is there. I've mimicked this in Power Automate using a created / modified trigger which works but it puts me as the created by when I would like the actual user who created it. Is there anyway around this?

Thanks

  • Sean Kuchle 

    Ok, so I can't find anywhere that says this is possible or how to do it, but I just figured it out, at least it works for me going cross site. So the trick is to utilize the built in move to command via REST API. There is a hidden little property on it that acts like a move but retains the source since copy doesn't retain metadata but move to command will. So this seems to work, here is a Screen of my test flow. I'll also paste the Body text down below so you can copy and paste, but it's actually pretty simple once you figure out all this undocumented stuff like the Conflictname behavior which I just guessed at to find the right number to override the name. You can also change that to a 2 if you want to generate a new file for each update instead, or 0 to do nothing if one exists. Anyway hope this works for you, not sure how it'll work with files already open for editing but hopefully it still copies and doesn't error when locked for editing otherwise I don't think it'll be possible. You can get status of the job etc. to do retries if that's the case but that's outside my time to spend on this limitations :).

     



    API: _api/site/CreateCopyJobs

    Body: 

    {
    "exportObjectUris":[
    "Link to Item from Get File Properties Step goes here"
    ],
    "destinationUri":"https://Your_Tenant.sharepoint.com/sites/YourSite/YourLibrary_NoSlash_at_end",
    "options":{
    "IgnoreVersionHistory":true,
    "IsMoveMode":true,
    "MoveButKeepSource":true,
    "NameConflictBehavior":1
    }
    }

  • Created by is always whatever account added the file, this cannot be changed, modified should be retained however. The only exception I've seen is bulk migration tools utilizing the bulk import methods.
    • Sean Kuchle's avatar
      Sean Kuchle
      Brass Contributor

      ChrisWebbTech 

      Thank you for your response. With the workflow and the impersonation step, the copied file would keep the created by and the modified would change to the impersonation account.

      Now with flow it is changing both the created by and the modified by to the account that created the flow loosing the meta data I need.

      Is there anyway to change this?

      • ChrisWebbTech's avatar
        ChrisWebbTech
        MVP

        Sean Kuchle 

        Ok, so I can't find anywhere that says this is possible or how to do it, but I just figured it out, at least it works for me going cross site. So the trick is to utilize the built in move to command via REST API. There is a hidden little property on it that acts like a move but retains the source since copy doesn't retain metadata but move to command will. So this seems to work, here is a Screen of my test flow. I'll also paste the Body text down below so you can copy and paste, but it's actually pretty simple once you figure out all this undocumented stuff like the Conflictname behavior which I just guessed at to find the right number to override the name. You can also change that to a 2 if you want to generate a new file for each update instead, or 0 to do nothing if one exists. Anyway hope this works for you, not sure how it'll work with files already open for editing but hopefully it still copies and doesn't error when locked for editing otherwise I don't think it'll be possible. You can get status of the job etc. to do retries if that's the case but that's outside my time to spend on this limitations :).

         



        API: _api/site/CreateCopyJobs

        Body: 

        {
        "exportObjectUris":[
        "Link to Item from Get File Properties Step goes here"
        ],
        "destinationUri":"https://Your_Tenant.sharepoint.com/sites/YourSite/YourLibrary_NoSlash_at_end",
        "options":{
        "IgnoreVersionHistory":true,
        "IsMoveMode":true,
        "MoveButKeepSource":true,
        "NameConflictBehavior":1
        }
        }

Resources