Dynamic tasks assignment and access denied errors in declarative workflows [SPD 2007 only]

Recently – with SharePoint Designer 2007 – I realized a workflow where a specific task was assigned to a dynamically selected SharePoint group; quite an easy work thanks to the “Collect Data from a User” task action, which allows selecting the assignee with a workflow lookup (to a variable or to a list item field):

In my specific scenario:

· A custom list of the “Enabled Groups” was prepared on the web; this list was designed only with two columns: a column named “Group Name” (of type: “Person or Group”) and the standard “Title” column, hidden in the view/edit forms and automatically set to the name of the group specified in the “Group Name” column by a very simple custom “Data Completion Workflow”.

· The “Main List” – with the “Main Workflow” attached – was defined with a “Lookup” column – named “Ask to Group” – referencing the “Title” column of the “Enabled Group” list

· The “Main Workflow” was designed to dynamically assign the custom task to the SharePoint group specified in the “Ask to Group” field in the current list item.

The following figure shows the simple “Data Completion Workflow” behavior on the “Enabled Groups”:

The following figure shows the result of the dynamic task assignment:

Before the first deployment of the “Main Workflow”, every possible target SharePoint group was already created on the site collection, listed into the “Enabled Groups” list and assigned the permission level of “Contribute” on the “Tasks” list.

Everything worked perfectly in the production environment. After a few weeks, it was necessary to add a new group to the list of possible enabled SharePoint groups; I have done the following actions:

· I have created the new target SharePoint group (into the site collection)

· I have added a new item into the “Enabled Group” list, referencing the new SharePoint group

· I have assigned to the new SharePoint group the “Contribute” permission level on the current “Tasks” list.

I was sure it was enough! Unfortunately, after few minutes the members of the new target group told me that they were not able to complete the tasks assigned to them because they were receiving an “Access Denied” error when trying to access their tasks, as shown below:

How was it possible, considering that they were contributors on the “Tasks” lists?

After a quick investigation, I discovered the cause of the problem: the new target group was not authorized to read the custom task form (the ASPX page automatically created by the “Collect Data from a User” task action during the workflow deployment) which is located into the hidden “Workflows” library on the current web:

I have noticed that, during the initial workflow deployment, all the users and groups authorized on the current web (which was not inheriting the authorization settings) were assigned the read permissions on this specific form; the users and groups added thereafter did not owned this privilege! How to quickly solve this problem? And, most important: how to enable the web administrators to add new target groups in the future?

A quick manual solution consists in performing the following steps:

· Explicitly assign a permission level to the new group on the current web; for example, assign the “Read” permission level (please note that this step is strictly required: if the group has only the “Limited Access” permission level on the web – as a result of the permission assignment on the “Tasks” list – the following step has not the desired consequence! See below for further thoughts about this limitation…)

· Check-out and then check-in the custom task form page using SPD 2007 (and/or make any kind of modification to this page)

A nice automated solution consists in adding the check-out/in actions to the “Data Completion Workflow” associated to the “Enabled Group” list; in order to select the “Workflows” list, it must be temporarily unhidden using SPD 2007:

The result is shown in following figure: the members of the new target groups can access the custom task form because the group is authorized on that file.

[BTW: why this happens? I could not find any “official” documentation explaining this behavior; it looks like an event handler is acting on the hidden “Workflows” list, checking and assigning the permissions to all the users and group explicitly associated to the current web…]

What if the current web must inherit the permissions from its parent web? In this situation, it is not possible to explicitly assign a permission level to the current web on the new group; I have directly experimented that, without this assignment, the check-out/in action on the custom form page has no effects on the new group permissions. In this situation, I do not see any solution without installing custom code on the SharePoint servers (which, many times, is not an option; for example, this is not allowed in hosted environments like Microsoft BPOS).

If the installation of custom components on the SharePoint servers is allowed by the server administrators, I suggest this quick solution:

· Install the “Useful Sharepoint Designer Custom Workflow Activities” from CodePlex (a detail: in my environment, I needed to manually add the following line into the “authorizedTypes” section of the web.config: <authorizedType Assembly="DP.Sharepoint.Workflow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0298457208daed83" Namespace="DP.Sharepoint.Workflow" TypeName="*" Authorized="True" />)

· Modify the “Data Completion Workflow” associated to the “Enabled Group” list (again, before you need to temporarily unhide “Workflows” list): instead of doing check-out/in, use the “Grant Permissions on Item” custom activity to explicitly assign the “Read” permission level on the custom form page to the current group.

Before finishing this post, it is worth to notice that the problem of the “Access Denied” error here described does not exist in SharePoint 2010; this is a consequence of the fact that, in SP 2010, the custom forms created by the “Collect Data from a User” task action are XSN files, instead of ASPX pages. I suppose that the XSN files are retrieved by the hosting ASP.NET page using an elevation of privileges.

The following figure shows a custom task form accessed by a user belonging to a new group that is not explicitly authorized on the XSN file.

So... another reason to move to the SPD 2010 workflows :-)