Gotcha – Setting People Fields in Nintex

I was working on a question submittal and response tracking system last week and I got stumped with a Nintex workflow failing. There’s nothing like a long weekend to clear your head, because I had the solution in a few minutes effort this morning.

Problem Description: A question coming into one list, needs to create a slot for the response tracking in another list. Easy-peasy except that every time I tried to set the “submitter” field in my destination list to the “created by” value in my source list, my workflow was failing. Oddly enough it would give me the failed to start status, but when digging in deeper, the actual problem was “failed to update list item”.

My submitter field was defined as a person or group field that did not allow multiple users.

This morning, I found that I had to change the submitter field to only allow people, not people and groups. Once that change was made, the workflow completed successfully.

Workflow Blogs

I’ve been working on my presentation for the COSPUG Lightning talk next week. I’m going to be talking about SharePoint workflow and my codeplex project ( in particular. One of the things I want to talk about is how these solutions will upgrade to SP 2010 and how workflow has changed in SP2010.

Today I happened across these two blog postings from Phil Wicklund at SharePoint Happenings. – Favorite updates in SP2010 workflows. – A listing of new workflow activities and conditions available in SharePoint Designer 2010.


WSS Activities Released on Codeplex

In the spirit of Christmas, I’ve just released a new project on Codeplex. WSS Activities ( contains 17 new activities for your SharePoint Designer workflows.

The code itself has been ready for a while, but I’ve been holding off on the release until I got some documentation done. However, I just got the Codeplex warning (You have 10 days left to publish this project), and I’ve decided that if I wait for the documentation, the project may never get released. There is some documentation on the site and more to follow.

The activities fall into two major groups. :

Site Management Activities

These allow you to manipulate various aspects of a site as well as create new sites. I created a site provisioning workflow for a client and this was every activity I needed that wasn’t provided out of the box. Documentation for each of these, though the activities’ names are probably enough to get you started.

  • Create Site Collection
  • Create SubSite
  • Lookup Site Template ID
  • Set Site Title
  • Set Site Theme
  • Create Site Group
  • Setup Site Group
  • Set Available Templates
  • Activate a Feature
  • Set Site Masterpage
  • Set Portal Link
  • Set Site Property
  • Get Site Property

Item Management Activities

These activities allow you to manipulate specific items or documents within a site collection or across the site collection boundary. Of these, Copy, Delete, and Update are fairly straight forward. It’s “Publish Item and Link to Another Location” that requires some further explanation. This activity creates a remote copy of a source item and puts in place an event handler that keeps the remote copy up to date with the source version. Additional columns are added to the source list and destination list to track the linkage between the two.

  • Publish Item and Link to Another Location
  • Copy Item To Another Location
  • Delete Remote Item
  • Update Remote Copy

Custom Designer Workflow Impersonation

You know that all the built in SharePoint Designer workflow activities (declarative workflows) impersonate the user that started the workflow.

If you write your own SPD workflow activities, and you want them to behave the same way, then don’t forget to pass CurrentUser.UserToken into any new SPSites you are using.

Consider the below example of an Execute function that sets the title of a site. If you change this line:

using (SPSite site = new SPSite(SiteURL, __Context.Web.CurrentUser.UserToken))

to this:

using (SPSite site = new SPSite(SiteURL))


then the code that updates the title will be running as your workflow’s privileged account, just as though you were using a RunWithElevatedPriviledges block.

SPSecurity.RunWithElevatedPrivileges(delegate(){ });



protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)




using (SPSite site = new SPSite(SiteURL, __Context.Web.CurrentUser.UserToken))


using (SPWeb web = site.OpenWeb())


if (string.IsNullOrEmpty(NewTitle))


NewTitle = “”;



string oldTitle = web.Title;

web.Title = NewTitle;



string message = “Site: “ + SiteURL + “; renamed from “ + oldTitle + ” to “ + NewTitle;

WorkflowHistoryLogger.LogMessage(executionContext, SPWorkflowHistoryEventType.None, “Complete”, UserID, message);




catch (Exception ex)


WorkflowHistoryLogger.LogError(executionContext, UserID, ex);

return ActivityExecutionStatus.Faulting;


return ActivityExecutionStatus.Closed;