Are you a user?

Here’s a good thing NOT to do.

• Open SPD 2010 at the site collection level and go into the workflow assets.
• Make a copy of the Publishing Approval workflow using copy/paste.
• Decide that you really didn’t want to do it that way and delete your copy of the workflow.
• Amazingly, all the Publishing Approval workflows are deleted.
• Close SPD, thinking that this must be a user interface glitch.
• Open SPD and verify that the workflows have indeed been deleted.
• Start working on a way to get the Publishing Approval workflow back.
• If you don’t have a lot of customized WFs yet, deactivate and reactivate the Publishing Approval workflow.
• Use "Copy and Modify" in the future.

If you need to update a URL field in a links list (or any other list) from SharePoint Designer, you need to know this little trick.  Create a string that contains the URL and description like this:

URL, Description

and then update the field with this string.  Notice there is a comma AND A SPACE after the URL.  There are no brackets, curly braces or octothorpes (# signs) involved in the string.

Using the string builder, you can see the "input" and the "output" of the workflow.

Since I originally published this, I’ve found that you can simply store the date in a dynamic string and then test the string to see if it is empty.  Use the “Build Dynamic String” action.

Testing the variable to see if it is empty.

Even easier!

Here’s the original post.

I was recently teaching an Advanced SharePoint class in Richardson, TX and a student was expressing his frustration over Microsoft’s apparent oversight within the SharePoint Designer workflow wizard. One of the “IF” conditions is a simple testing of the value of a field…”If this equals that.” He wanted to test a date field in SharePoint to see if it was empty or not. Problem is, when you select a field that is typed as DATE in SharePoint Designer, there is no test for the empty or null condition. You can see this in the first figure.

It occurred to me that we might be able to change the type of the field to a string and then be able to perform the comparison. I used the “Build Dynamic String” action.

I selected the End Date custom field on my Expense Statements list and stored it in a new variable that was typed as STRING.

The results of this were not exactly what I expected, however I was able to determine, through trial and error (sending the values in an email), that the conversion created a string that was filled with question marks (????). Therefore, if you simply test to see if the new string begins with a ?, you can successfully test for an empty date value.

Both my student and I were happy with the results.

A.K.A. – A timer does not resume operation after a workflow is reloaded in Microsoft Windows Workflow Foundation

Here’s something that’s kind of hard for me to believe.

I’ve been working on an SP2 patch-level SharePoint site developing some SharePoint Designer workflows.  Nothing complicated, mind you, but they will be getting much more complicated.  All I have to do is prove you can do what we need to get done with an SPD workflow. 

I’ve got 12 workflows that start automatically on creation of a list item, thus assigning 12 individual tasks.  The workflow(s) I’m creating are very simple.  They look up people based on a role from a SharePoint list.  A variable is set with the person (approver) that is looked up.  They pause until a certain day at a certain time and then each workflow executes the "Collect Data from a User" action.  There is one of these actions for each of the 12 workflows.  This essentially creates 12 tasks (in Workflow Tasks) in response to entering an item in a SharePoint list.  Pretty simple.

There is also a secondary workflow that gets spawned on each task that is created as a result of the “Collect Data from a User” action in the primary workflow.  The secondary workflow (on the Workflow Tasks list) pauses for a certain amount of time and, when the pause is over it inspects the status of the task.  If it is not complete, it updates the assigned to on the task with a backup approver.  Again, not a very complicated workflow.

The problem is that the "Assigned To" field on each of the tasks that are created in the Workflow Tasks list are not being set to the person the task is assigned to.  Many times I get 3 of the tasks that get the "assigned to" set correctly.  Some times more.  It appears to be very inconsistent.  Many times the “assigned to” field is blank (never filled out).  The history list many times shows “error updating a list item.” 

What have I tried to get around this problem?  I’ve tried using the trick of prepending -1;# to the user name per this article.  I originally had all the task assignment actions in a parallel step in a single workflow before breaking them out into multiple workflows.  I’ve tried updating the assigned to in another workflow that is started automatically on the task.  Nothing seems to give consistent results.

Perhaps I’ve stumbled upon the root cause of all my woes.  I was searching the web and ran across this post.  This indicated that I needed the update to the Windows Workflow Foundation described in KB932394.  I know that I had seen a reference to this fix from other posts, but the actual article is from 2007.  I ASSumed, incorrectly, that this fix would be part of one of the SharePoint cumulative updates or, at the very least, a service pack.  Not so!  My original files (after SP2) were version 3.0.4203.2.

After applying this patch, the file versions were 3.0.4203.201. 

Now, I know that TECHNICALLY the files are part of the Window Workflow Foundation, but wouldn’t you think they’d be included in a SharePoint service pack?

What other patches do I need to get to insure that declarative SPD workflows will be processed correctly?