Monday, 24 November 2008

Workflows not being associated with lists/libraries

I don't often do "a funny thing happened to me on the way to configuring a SharePoint farm recently"-type posts, but I'm making an exception here - this issue not only took a bit of figuring out, it's also kind of interesting! This is partly because SharePoint doesn't do what you'd expect it to do under the circumstances, and you could probably chase your tail for a while on this one if you didn't think it through. 

Scenario:-

  • Workflow is not enabled on any of the lists/libraries in the site in production - specifically, there is no association so the workflow list is empty
  • The workflow we were expecting to see enabled is the standard publishing approval workflow - since we are in a WCM/publishing site scenario, this would be associated with each Pages list in the hierarchy
  • In our case, initial configuration had just been completed by the hosting company and we were asked to start our testing. Search configuration has not yet been performed
  • Previous environments did not display this behaviour
  • A custom site definition is used to create any site/web - this is what determines the approval workflow should be associated

At first it seemed like an issue with the site definition. I was thinking that the hosting company had missed a deployment step to STSADM upgradesolution on the .wsp containing the site definition, but accessing the servers showed the latest files in place. I knew that because search configuration hadn't been done yet, the hosting company hadn't yet created the SSP - this was their next task. I couldn't initially see a link between the SSP and workflow (since SharePoint workflows execute in the w3wp.exe process), but then I started wondering if there was any indirect link, and came up with this as a chain of dependencies:

 image

Could it be that the sites didn't have workflow enabled because the SSP wasn't there at time the sites were provisioned? Sounds plausible, but then I thought hang on - surely what would happen is that workflow associations and so on would be there as usual, but when a workflow form is accessed it would error with the familiar message that session state must be configured:

InfoPathSessionError

Well, as you might have gathered, the answer is no, this isn't what happens! SharePoint genuinely will not (or cannot) add the workflow associations to your lists/libraries, and furthermore they will not magically appear when your SSP is created. You will need to go back and configure workflow on each list/library (or content type) either through the UI or with code.

So the moral of the story is:

Create your SSP before any sites are provisioned!

4 comments:

Broschat said...

Here's another SSP-related issue we happened into.

Although we haven't started creating workflows yet, we've attempted to use the canned ones, at least for experimentation. One experiment worked magnificently--until someone from another domain attempted to use it.

Eventually, I discovered that although the other-domain users were perfectly authorized, their profiles had not been imported from Active Directory (for a yet unresolved reason). I manually created profiles for a couple folks--including only their email address--and leaving off a couple other folks (as a control). Only the folks with email-included-profile ever saw a workflow step.

Robin Meuré said...

Hi Chris,

isn't this issue bound to workflows that use InfoPath forms for their initiation forms? Seems to me that workflows should properly work without SSP since the SSP is MOSS only and the whole workflow component isn't..

Robin

Chris O'Brien said...

Hey Robin,

Yep, I probably should have been clearer - but since I think all the standard workflows use InfoPath forms they'd be affected.

C.

velocity boy said...

Hi Chris,

Just wanted to let you know about the utility we've open sourced. This is the one I mentioned at the SpUG meeting in London a few weeks back.

ShUIE = SharePoint User Interface Extender

It allows you to dynamically (according to context) insert JavaScript and CSS into any SharePoint page.

The announcement is here:
http://www.buro9.com/blog/2008/12/04/announcing-shuie-sharepoint-user-interface-extender/

And the code and documentation is here:
http://www.codeplex.com/ShUIE

Cheers

David