locked
SPD Workflow Copy Document Loses Metadata RRS feed

  • Question

  • Hello,

    I have a custom Sharepoint Designer approval workflow that copies a document with metadata from one library to another within the same site.

    I have a problem with this document losing data during the copy in one column only.  There are about 10 columns in total and all the other columns get populated correctly in the destination, except this one.  This one column happens to be a multi-select Choice type.

    Everything was scrapped and rebuilt from a previous iteration which was having a similar problem.  Workflow was recreated with this 2nd iteration, of course.  These columns are all created as site columns, added to a custom content type, which is then applied to both the source/destination libraries.  The libraries, column names, types, choices are as identical between both as they could be.  I still experience the data disappearing on one column. 

    Ideas?  What can I look for, where can I go get information about this failure?  I've tried Googling to no avail...

    MOSS, SP2


    Thanks,

    Eric

    Thursday, November 17, 2011 12:36 AM

All replies

  • Hi Eric,

     

    As you mentioned, the losing field is a multi-select Choice type. You can check that if the settings of this column is exactly same between source library and destination library. Like “allow fill-in choices” and so on.

     

    When you using copy list item activity, the fields are considered compatible for copying when the following is true:

     

    Ÿ   The source and target field names are the same.  It compares the field name you see in the browser (SPField.Title), not the internal/static name (SPField.InternalName)

    Ÿ   The source and target field are the same type

    Ÿ   The source and target fields are compatible.  For example, if the source field allows multiple selections, but the target does not, or the source allows selecting people and groups, but the target only allows selecting people

    Ÿ   When the source field is a lookup to another list, the target field must use the same list

    Ÿ   The source field is not read only

    Ÿ   The source field is not a special field, such as ContentTypeId

     

    You can refer to this article, hope it could shed you some light.

     

    http://blogs.msdn.com/b/johnwpowell/archive/2009/01/02/sharepoint-designer-copy-list-item-workflow-activity-does-not-copy-all-fields.aspx

    Thanks,

    Pengyu Zhao

    Friday, November 18, 2011 8:32 AM
  • Hi Pengyu,

    Thanks for the reply. The link provided is actually one I have reviewed before.

    (from the link)

    When a SPD workflow doesn't copy one field to the target list:
    
        - The field names don't match
        - The field names match, but the field type and the settings do not 
    

    Note, all of my columns here are created as Site Columns, added to a Content Type.  That content type is applied to both libraries, and none of the columns have been modified in either library after that.  In fact, I think I even saved the first library as a template, after adding the content type, and created the 2nd library from that template to ensure both libraries were as identical as I could make them.  Doing this negates all of these points, no?

     

    I still have this problem.  I ran out of ideas long ago...but this has resurfaced as something that must be addressed, so I'm looking for an answer.

    • The source field is not read only - This workflow is run by somebody with Manage Hierarchy permissions on the source and Approve permissions at the destination.
    • The source field is not a special field, such as ContentTypeId - The source field is a standard Sharepoint Multi-Select(check box) Choice, no fill-in allowed in either library.

    As I mentioned, this is the 2nd iteration.  The first time had a similar problem with a different field.  Everything was scrapped and rebuilt this way because even creating a new column to replace the problem column did not work.  Thoughts?

    Thanks,

    Eric

    Saturday, November 19, 2011 12:13 AM