Archive for the 'SharePoint Workflow' Category


The Infamous “Error updating a list item” Error Message on a SharePoint Designer Workflow

I can’t tell you how many times I’ve seen this error message while creating SPD workflows.  Many times it is a permissions problem, as the workflow is generally running under the context of the credentials of the person who initiated it (at least in 2007).  Since the limitation exists in SPD 2007 workflows to not easily change the security context of the running workflow, I usually tighten the security around the lists and libraries I use to insure those participating in the business process workflows only have the security needed to function in their assigned role.

This particular "error updating a list item" problem was due to my overzealousness to log as much info as possible to the workflow history list.  Here’s what I was logging:


It turns out that that is too long!  If you look at the Description field on the Workflow History List you can see that it is defined as a single line of text, i.e. it can accept no more than 255 characters.  My log message exceeded this limit.

If you haven’t looked at the Workflow History List in SharePoint through the browser, you can use SPD to enable it so it shows on the "View all site content" page.  You can find it under the LIsts folder and select the properties sheet and uncheck the "Hide from browser" checkbox.



Checking for a NULL Date Field in SharePoint Designer 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.


Changing the Group on a Site Column Causes Hidden Fields to Display on a Content Type

I ran into this problem recently.  I had a number of site columns that were hidden on multiple content types and I "recategorized" the site columns into a single group (simply for administrative purposes).  As a result, all my forms began displaying the hidden fields (instead of keeping them hidden).

Here’s the scenario.  I have a content type, Generic Task, that is used as the parent of many other content types.  You can see from my first screen shot that I have a content type (called Badge Access Task) that is inheriting from Generic Task.  When a user interacts with the task list Edit form I only want them to see and update the two fields at the bottom (Badge Access and Badge Access Comments).  All the other fields are hidden and are only used by workflows.  If you haven’t done this before, you can still see the hidden fields in a view, but the New, Display and Edit forms don’t show the hidden fields.



Here’s the problem I was having.  After I changed the group that my Generic Task site columns were in, they all started showing up on my Edit forms.




To correct this problem, I simply went into each site column on each content type and clicked OK.  I didn’t make any changes to any of the information on the form.




This appears to have had the desired effect.  After performing this procedure on each site column on the content types, all of my fields were again properly hidden.




As an FYI, this is on an MOSS 2007 farm with SP2 (and patches) applied.


Error Updating List Item in SharePoint Designer Workflow – KB932394

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?





Great Example of a SharePoint Designer Workflow Solving a Scheduling Problem

Ran across this on Paul Galvin’s site.!1CC1EDB3DAA9B8AA!3133.entry

Hey, what do you know, it’s one of my posts!  Thanks for the nice words, Paul!

Asif Rehmani’s SharePoint Videos


Click to access a wealth of SharePoint videos

SharePoint Rx

SharePoint Rx Home


Posts by Date

December 2022
Support Wikipedia