If you are trying to get a value from a multi-select people picker in workflow in the same way as you would from a single select people picker, then you are going to have problems.
I came across a great post (my salvation) here:
-which saved me a lot of time and headache. But just incase I’ve posted a screenshot below. Worked a treat for me (in this example, the multi-select people picker field is called Members).
After migrating a SharePoint site to a new collection; which utilised a globally reusable SPD workflow, I of course expected that the workflow would not be available to the migrated sub site until I published an update. What I didn’t expect though was that updating the workflow would break it everywhere.
First of all I tried updating the workflow settings on the content type (in this case Document) to cascade the workflow settings down to all child content types (including those in the migrated sub site). This got me one step closer to my goal as the workflow then appeared associated with documents in the sub site, BUT once I tried to start a workflow, I got a big fat error: User cannot be found.
So next I opened SPD and updated the workflow and republished it (globally). That all worked and so I tested the workflow in the sub site again- User cannot be found.
So next came Google. I found plenty of people reporting the issue and many of those also bagged Microsoft for telling them that it could be fixed by simply re-publishing the workflow. Since I’d already tried that, I sympathised with their frustration.
Finally, with the magic of Google, I found this post which gave me the right answer. I logged in as an SCA and deactivated and then activated the site collection workflow feature and then started a workflow in my sub site.. Success!
I can’t believe I hadn’t attempted to do this earlier but last week I was setting up a sort of dashboard page for a SharePoint audit site and I found I wanted to display a list of the site’s In Progress workflows. I had set up a simple SPD workflow on a list, which acted as the source and storage for the workflow forms, so consequently it had the Workflow Name column to display the status. When I created an “In Progress” view on the list web part, I got a strange Render Error. It became clear that I could not filter the list where the Workflow Name column value = In Progress. So after some digging around I discovered that the SPD workflow statuses are actually represented by numerical values not text, so here are the mappings:
2: In Progress
So get filtering 😉
Why SharePoint does not treat workflow tasks like any item requiring content approval I just don’t know. If a page, item or document is hidden from non-approvers (until approved) then why would the task requesting the approval be visible to all? There are of course “options” to control who can read and edit workflow tasks but I haven’t found a suitable setting to allow members of an Approval group access to read and edit tasks while ensuring that general user mind their own business.
So when I had to put together a site collection-wide My Tasks web part (No Code Allowed- only CQWP config) that displayed all tasks and workflow tasks assigned to a user (including tasks assigned to groups that the user is a member of) I was scratching my head. I used an extended CQWP to display all task content types across the whole site collection where assigned to = [Me] but then this excluded tasks that were assigned to groups containing [Me]. There just isn’t a reusable My Groups filter available in this case.
So what I ended up doing was configuring 2 CQWPs: 1 to display Tasks assigned to [Me] and the other to display items of the Office SharePoint Server Workflow Task content type. I then turned content approval on on the site Workflow Tasks lists and hid the Moderation status from the allitems view. Now, when SharePoint creates a new workflow tasks i.e. a publishing page approval task, it is automatically added to the list in a pending state. The site’s Approver group members are therefore the only users that can see these ‘pending’ workflow tasks so they only display in those user’s My Tasks web part. Its not important whether the workflow task item is approved (in fact we want them to stay in the pending state) because this does not effect the actual page approval. The Approvers can edit the task and approve the page while the task item is pending. This is a pretty crazy convoluted way to make workflow tasks contextual to the current user but it seems to work.
If you have applied MOSS/WSS Service Pack 1 or one of the recent MS Security hot fixes to your environment you may have noticed that workflows once initiated by SharePoint are no longer starting as expected. I came across this issue when developing and testing a timer job which called a SPListItem.Update(). I expected this update to kick off the attached SPD workflow but.. nothing happened. The workflow never started. This was because the timer job was running under the web application pool account which is a SharePoint service account. This issue is outlined in this MS article: http://support.microsoft.com/kb/947284.
The solution supplied in this article was not suited to our needs so the workaround was to impersonate a non-service account when accessing the list and updating the items. A useful resource is this impersonation class which is quite neat because it is instantiated using the using a using-block which allows the tidy release of the resource: http://www.codeproject.com/KB/cs/zetaimpersonator.aspx .
In my case, I added the impersonation account details to a settings database and retrieved these in the timer job via a web service. It is important to note that the impersonation should encompass your SPweb and SPsite using-block code, not just the actual update call. Also, the impersonation account must have the current level of access (at least contribute) to the workflow hosted site and list.
using (new Impersonator(_username, _domain, _pwd))
using (SPSite wfSite = new SPSite(TargetSiteURL))
using (SPWeb wfWeb = wfSite.OpenWeb())
SPList wfList = wfWeb.Lists[TargetListName];
foreach (SPListItem item in wfList.Items)
While knocking up a document review process using a document library, a custom content type and SharePoint Designer workflows, I noticed that my main workflow, which is initiated by a new item, was kicking off after I had uploaded a document but before I had completed the associated content type columns. This is what my content type “form” looked like at this point:
You’ll notice that the Deliverable Status field is a Required Field and it has a default value of ‘In Progress’. I was almost there but not quite- I had to modify the content type to remove the default value like so:
This forced SharePoint to wait for a value to be selected before officially creating the new item. After this change my workflow was initiating right on time.
So, the main points to remember here if you are having this problem are:
1) One of the fields in the content type must be a Required Field
2) This Required Field should NOT have a default value so a user input is required