The Task: Build a system to archive paper documents (being scanned from e-mail enabled scanners) and optimize for retrieval
I decided to build an E-Mail enabled library to get the documents into SharePoint. This allows users to save the email address in their contact list on the copier, and makes scanning in documents very easy.
To gather the metadata for these documents, I used the “Collect Data From a User” (CUD) Action in SharePoint Designer. This created a Content Type based on the name of the task – In my case “Student Document Data Collection.”
I then added some of my existing site columns to this content type from SPD – things like first name, last name, and district. I didn’t want to use the CUD wizard to add these fields to the data collection task because a) all of the fields already exist in the site, and b) some of the fields are multiple choice, and I really don’t want to manage two instances of the same data!
After I modified the content type, I refreshed the workflow and returned to the CUD wizard in SPD, and saw that all of my fields populated! Hoorah!
I proceeded to build the rest of the workflow, referencing the fields collected in the CUD task in the normal manner; however, I was noticing a problem: None of the user entered data was showing up!
How could this be? SharePoint was prompting me for the data, I entered it, and I hit save… It should be there, right? I wrote entries to the workflow history log to see if maybe the data just wasn’t being applied to the current item. No dice – It looked like SharePoint just wasn’t storing the collected data.
Thanks to reddit user sbrick89, It looks like fields (Site Columns) created in the CUD action within SPD actually have a distinction from standard Site Columns! It’s not a big difference, but it will mess up your day (or, in my case WEEK)! These fields are prefixed with “FieldName_”.
I jumped into my SharePoint Management PowerShell and whipped this up in order to create my Site Columns (in a way that they will be usable for data collection):
$SiteURL = “<YOUR SITE HERE>”
$Web = Get-SPWeb $SiteURL
$FieldXMLString = ‘<Field Type=”Text”
Name=”FieldName_StudentFirstName”
Description=”Student First Name”
DisplayName=”Student First Name”
Group=”0 Student Columns”
Hidden=”FALSE”
Required=”FALSE”
Sealed=”FALSE”
ShowInDisplayForm=”TRUE”
ShowInEditForm=”TRUE”
ShowInListSettings=”TRUE”
ShowInNewForm=”TRUE”></Field>’
$Web.Fields.AddFieldAsXML($fieldXMLString)
Documentation for the syntax of the $FieldXMLString can be found here: https://msdn.microsoft.com/en-us/library/office/ms437580(v=office.15).aspx
Of note is this “Name: Required Text: The name of a field. This is the internal name of a field and is guaranteed never to change for the lifetime of the field definition. It must be unique with respect to the set of fields in a list. The name is autogenerated based on the user-defined name for a field.
I also wanted to create a multiple choice Site Column for District:
$FieldXMLString = ‘<Field Type=”Choice”
Name=”FieldName_District”
Description=”District”
DisplayName=”District”
Group=”0 Student Columns”
Hidden=”FALSE”
Required=”FALSE”
Sealed=”FALSE”
ShowInDisplayForm=”TRUE”
ShowInEditForm=”TRUE”
ShowInListSettings=”TRUE”
ShowInNewForm=”TRUE”>
<CHOICES>
<Choice>District 1</Choice>
<Choice>District 2</Choice>
</CHOICES>
</Field>’
$Web.Fields.AddFieldAsXML($fieldXMLString)
After creating the Site Columns with the proper internal name, I was able to add the newly created site column to the CUD Content Type, update my workflow, and collect the user data successfully! Yes, It does seem that any alterations (including changes to the items in a choice Site Colume) to the CUD Content Type require that the workflow be loaded in SPD, the CUD Step opened, “next through” the wizard, and the workflow re-published in order for the changes to appear in the actual data collection step.
Links:
http://www.sbrickey.com/Tech/Blog/Post/Secrets_Revealed-_SharePoint_Designer_-_Workflows_-_Approval_Task_-_Task_Form_Fields
