SharePoint Designer 2007 workflows that contain actions such as Collect data from user or Assign a Form to a group exhibit inconsistent behavior, after upgrading to SharePoint 2010 or SharePoint 2013, depending on the columns used in the SharePoint 2007 workflow actions.
For instance, if one of the two actions mentioned contain a lookup column then the form page that uses the DataFormWebPart will produce the following error when users try to complete a task in a browser:
Cannot complete this action. Please try again
The following can be found in the ULS logs:
[Date and Time] w3wp.exe (0x13F4) 0x0F24 SharePoint Foundation Runtime tkau Unexpected System.Runtime.InteropServices.COMException: Cannot complete this action. Please try again.
Also, if you try to upgrade to the InfoPath-based forms the form generation process will produce an error and columns will be missing.
This happens because the SchemaXML of the lookup columns is not fully upgraded to 2010.
Also, the InfoPath form that is auto generated will not support the following fields:
Lookup Calculated Page Separator Extended field
These fields have been removed from the Assign a Form to a Group and Collect Data from a User actions on the 2010 platform.
The solution is broken down into two sections.
1. The first section is to address the, "Cannot complete this action. Please try again." error. 2. The second section is to address the missing form fields in the InfoPath form that is auto generated/not supported by InfoPath in this given scenario.
Solution 1 =================== To address the, "Cannot complete this action. Please try again." error message we'll need to update the SchemaXml for lookup columns.
1. Click Site Actions > Site Settings > Site Content Types and click on the name of the Content Type that was created by one of the two actions. 2. Click on each custom column name and then click Edit site column.
Note: This can done to all the columns to be on the safe side. No changes are being made to the configuration, per say, but rather by clicking OK the columns upgrade fully to meet the 2010 requirements.
3. Click OK.
This could be done programmatically as well by setting the SchemaXml property using the pattern described later in this solution.
NOTE: Any attempts to create a new custom list form against the content type created by the Collect Data from a User or Assign a Form to a Group actions will result in CAML query error. By adding the content type to a list it will produce the error as well when trying to edit list items.
Here is an example of what the SchemaXml property looks like right after upgrading to 2010 but not applying the workaround:
Once the workaround has been performed users should be able to complete tasks using their 2007 workflows and users should be able to create new DataFormWebParts using these content types.
NOTE: This might need to be done for the other 3 columns as well if the issue still persists. The SchemaXml property is that of a lookup column. The following are the other potential columns:
Calculated Page Separator Extended field
Solution 2 =================== The second solution address the missing functionality in the InfoPath form that is auto generated. This workaround also alleviates the need to recreate the functionality of the DataFormWebPart based form pages since users cannot opt out of the upgrade process to InfoPath.
The Edit Form page, for the list level content type, needs to be set to the aspx page inside of the workflow instead of the new URL.
The Edit form page for the content type on the task list after upgrading is set to _layouts/WrkTaskIP.aspx. The same URL applies for any newly created 2010 workflows that contain the two actions previously mentioned. If a user does not upgrade their 2007 workflows to 2010 workflows they'll be pointed to the aspx page located in the workflow.
Here is an example of the URL:
To find the aspx page that contains your custom form perform the following:
1. Click All Files site object in SharePoint Designer 2010. 2. Expand Workflows. 3. Expand the workflow in question. 4. Take note of the aspx pages in the workflow. It should be named the same as the content type created by the two actions.
With the aspx page available the next step is to set the Edit Form page to this URL found in step 4 instead of WrkTaskIP.aspx.
1. Click Lists and Libraries. 2. Click on the Tasks list. Most SharePoint Designer 2007 workflows used the Tasks task list. 3. In the Content Type slab click the content type that was generated by the two actions mentioned in this article. 4. Paste the URL into the Edit Form text box and Display Form box. 5. Save the content type.
1. Don't perform these steps on the Site Content Type level.
2. The original aspx pages can be used to complete your tasks for actions such as Collect Data from a User or Assign a Form to a Group.
3. The new approval process action could be used instead of these older actions but would require a higher overhead and the loss of the aspx pages.
4. There might be a need to update the content type's Form URLs if the URL is set back to WrkTaskIP.aspx.
5. Generating a new xsn template poses challenges such as completing tasks by posting to host environment which makes this solution difficult. If the columns that are no longer available are removed then the auto generated form will work fine in all scenarios, unless the original DataFromWebPart had extensive customizations.
6. Finally, if more than 8 lookup columns are included there is a chance that SharePoint will throttle the task list and this will prevent users from completing the task list item. This setting is located in Central Administration per web application under Throttling Settings. Look for the following error in the ULS logs if the tasks are not getting completed or the workflow goes into an error state:
w3wp.exe (0x2E04) 0x33DC SharePoint Foundation Fields fzn4 Medium