Tuesday, June 28, 2011

An error has occurred in <workflow name>

I was receiving an error in my SharePoint Designer 2010 workflow on an approval action.
The error read:
An error has occurred in <workflow name>
I know, very helpful.
There was not anything helpful in the logs either.

I spent an hour trying various things like:
  •  Removing task form fields
  •  Removing actions I have inserted in the single task behaviour as well as overall task process.
With no luck I finally decided to hard code the assigned to person.

After a little investigating I figure out that the lookup person / group I have assigned needs to be returned as “display name” instead of the default, string

Monday, June 27, 2011

Setting the priority of a task in SharePoint Designer 2010 workflows

In your SPD workflow on the task process there is a link under the customisation section called 'Change the behaviour of a single task' where you can edit the task behaviour.

In this area within the 'Before a Task is Assigned' step you can add a 'Set Task Field' action. Using this action you can set the priority of the task

Friday, June 24, 2011

Upgrade existing InfoPath 2007 form (including data) to new InfoPath form version

My problem:
My client currently had an InfoPath form published to a forms library in SharePoint. They wanted some amendments made to the form, including additional fields.
They wanted all the existing forms within the library to have all the new version's amendments.
This was not going to be possible with a normal InfoPath form upgrade.

My solution:

What I did was:
  1. Extracted the data from the old form and temporarily stored it.
  2. Created a new form with the same name and overwrote the existing form.
  3. Populated the new form with the stored data.
All this was done using 2 workflows. (I am currently using Nintex Workflows).

First workflow
  • Using workflow actions:
    • I query the list for all items matching the content type version 1 of the InfoPath form.
    • I loop through the results of this query:
      • using a 'Query XML' action, I retrieve the data from the existing form.
      • I create a new item using the 'Create an item' action. I set the name to exactly the same name as the current form item and specify 'Overwrite an existing item'. I store all data retrieved in the 'Query XML' in a temporary field value which I called 'Form XML'. When the new item is created it overwrites the current item preserving it's ID.
      • I then kick off a second workflow using the Nintex web service method called StartWorkflowOnListItem. (http://<site>/_vti_bin/nintexworkflow/workflow.asmx). This workflow kicks off on a specific item specified by the list item ID.
Second Workflow
  • Using multiple 'Query XML' actions I retrieve the data from the temperary field I stored it in.
  • Using an 'Update XML' I update the new form with the old data.
That sounds simple enough :)
I have excluded any business rules I have in my current workflows for the purposes of this blog.

Some of you might be wondering why I used a temperary field to store the data instead of passing the data via the web service method using the associationData tag.
I had issues when passing the data using the a associationData tag. The temperary field was a quick and easy workaround I could implement as this solution was going to be used as a once off to upgrade existing forms.