This blog is now obsolete. Go to scott.arbeitman.id.au for all new content.

Microsoft Madness (Enterprise Edition)

| Monday, May 5, 2008

We just launched our first deliverable of our internal SharePoint project, codename MBS Direct. As part of this first release, we needed to migrate some functionality from our old infrastructure onto the SharePoint platform. This functionality was simple: show a list of events and allow the user to sign up for the event. I decided I would give it this a shot, despite have no development experience with SharePoint (although I was comfortable configuring lists and such). After playing with InfoPath for forms and Visual Studio for workflows for a couple of days, I decided to give SharePoint Designer a go. After hitting a wall trying to pass variable data into the start of a workflow, I found this useful tutorial which essentially mirrors the functionality I was trying to accomplish. Lucky break! (Still, the way to pass data into the workflow when it starts doesn't appear to be documented anywhere but there.)

However, once everything was set up -- forms, workflows, lists, permissions -- things turned sour when I tried testing this solution as a standard (i.e. not administrative) user. I kept receiving "Access Denied" errors when the workflow ran. I tried some obvious things, not the least of which is was make sure visitors have contribute access to this list that workflow adds to. No effect. It was difficult to determine to what, exactly, access had been denied. Troubleshooting SharePoint errors is a bitch, to say the least.

I gave up; there was no way I was going to solve this problem myself. So we asked the company looking after after our support to help.

First, kudos to So what was the problem? Here's the first sentence from the "solutions architect" who managed to solve this problem several days after it was raised: "To resolve your workflow issue you need to give the user starting the workflow contribute access to a hidden list." This is certainly one of the funniest "features" I have ever come across.

So for those of you who encounter this problem, here's what you need to know. When you create a "custom workflow action" without explicitly binding the workflow to a list in SharePoint Designer, it will cleverly use a list called "Custom Workflow Process" located in the _catalogs folder of your site. You must set up the visitors to have contribute access to this list. And you must do this by looking at the properties for this list in SharePoint Designer, going to "Security" tab and then clicking "Manage permissions using the browser."

Crazy, right?

0 comments: