(this post was written using a SharePoint 2010 environment)
This post details the steps involved in delegating or reassigning a workflow task to another person as part of a workflow process.
My organisation has several approval workflows in action within our SharePoint 2010 environment, but one request I get all the time is to change who the approval has been sent to.
Approval tasks can be assigned as part of a workflow process, built via SharePoint designer or Nintex workflows. Once assigned, notification message(s) are sent to the approver and can either be approved via the Workflow Tasks section of a current item or via lazy approval if you have Nintex.
As this can be done with both regular SharePoint designer workflows and Nintex workflows, I’ll detail the steps below on how to switch the approver for both types of workflows.
Reassign a workflow task in SharePoint Designer workflows
In this example I have the following components configured:
A custom list with two columns: Title, Assigned To
A SharePoint Designer workflow that starts an approval process action on the current item and sets the approver as the person listed in Assigned To
Approval tasks are created within the workflows associated task list
An example SharePoint Designer workflow that uses the “Start Approval Process” task action on the current item and sets the approver as the person selected in the current item’s Assigned To field.
The steps below will demonstrate how to reassign an approver inside a workflow task:
Open your main list (in my example the custom list)
Either click on the status of your workflow for the current item (if column is displayed), or highlight the current item > under List Tools > Items > Press Workflows
NOTE: In some cases, the site owners or SharePoint admins may have hidden the workflow status column that gets created when you publish your workflow. If you can’t see this column, don’t worry just follow the other method described above.
If you press the Workflows button > left-click on the name of your running workflow(If you pressed the workflow status from the previous step, ignore this step)
Press the name of your running workflow to access the workflow tasks.
Under Tasks > click on the drop-down icon next to the title or your task > Press Edit Item
Press Edit Item by opening the drop-down menu next to the title of the workflow task.
A new pop-up window will open, at this point you will see the properties of the workflow task which includes:
Status – the status of the current workflow task (not started, approved, rejected)
Consolidated comments – Comments of the requester and all previous participants
Due date – the date set for workflow tasks to be completed by
Comments – allows the approver to enter any comments about why the item was approved or rejected
The workflow tasks pop-up window.
There will be four grey buttons at the bottom of the window > Press Reassign Task
Press the reassign task button.
In Reassign Task To > select the person you wish to reassign the task to and press Send
Delegate workflow tasks in Nintex workflows
In this example I have the following components configured:
A custom list with several columns, but namely: Title, Approver
Nintex Workflow 2010 version (2.3.10.0)
A Nintex workflow that uses a flexi task action to send an approval request task to the approver as the person listed in Approver column from the custom list
Approval tasks are created within the workflows associated task list
Flexi task to send approval to the person set in the current items Approver field.
The steps below will demonstrate how to delegate an approver inside a workflow task:
Open your main list (in my example the custom list)
Highlight the current item > under List Tools > Items > Press Workflows
Left-click on the name of your running workflow
Under Tasks > click on the drop-down icon next to the title or your task > Press Edit Item
Press Edit Item by opening the drop-down menu next to the title of the workflow task.
A new pop-up window will open, at this point you will see the properties of the workflow task which includes:
Outcome – the status of the approval task (approved or rejected) or delegate the task to another person
Comment – allows the approver to enter any comments about why the item was approved or rejected
Item Properties – a view of some of the list item properties for the current item associated with the workflow task
Within the workflow task, press delegate this task to change the approver.
Press delegate this task. At this point the pop-up window will change to display the following fields:
Delegate – this is used to specify the user to assign the selected task to
Comments – this is used to provide instructions or additional information to the user the task is being delegated to
To delegate to a new approver, click on the address book icon on the right to select a user from the Select People or Group dialog box
Add any additional comments in the Comments field. This text is appended to the ‘Approval Required’ notification that is sent to the delegated user.
Use the address book within the delegate field to assign the task to another approver.
It’s back again…a few months ago a wrote about my experiences with workflows failing on start after a .NET security update that was applied. You can read that post here:
Recently, the same .NET security update was applied to our SharePoint 2010 farm, which in turn caused the failing on start error to present itself again across all the workflows in the farm.
After identifing the issue soon after the update was applied, we decided to follow the same tact as before and roll back the patches, restart the servers and re-test the workflows – However, this time the results were different.
What was different?
Previously, rolling back the security update and any other patches added during this time, plus restarting the servers “fixed” the issue. This time, the same process did not yeald the same results and the workflows were still broken.
After performing the steps above, we observed that standard SharePoint workflows with a pause started to run sucessfully again, but Nintex workflows with a pause step either failed on start, or completed but errored after the pause step and sent an error notification.
Example 1 of nintex workflow with pause step failing on startExample 2 of nintex workflow with pause step erroring, but completing
How we fixed it…
So this time we followed the updated step-by-step guide provided below on how to update the web.config files and OWS timer files via Add-CodeDomAuthorizedTypeToOWSTimerConfig.ps1 PowerShell script on the SharePoint Application server.
We ran the script as recommended, which re-added the assemblies and dependancies to the OWSTimer config file and the web.config files on associated web servers and this in fact fixed the issue! As the script does an IIS reset/ Timer Job recycle we didnt even need to restart the servers!
I hope the that tidbit regarding the nintex workflow pauses helps someone else 🙂
I had this issue myself in the last week where EVERY SINGLE workflow across the farm on premise stopped working. SharePoint Designer and Nintex workflows all reported “Failed to start” when triggered to run.
The workflows stopped working due to a series of .NET security updates Microsoft released in September 2018. Microsoft released a public KB article on this – with resolution steps which can be found below:
I noticed shortly after the fix was implemented that some of my SharePoint designer workflows were exhibiting odd behaviour. For example the screenshot below shows a SharePoint desinger workflow that previously worked without issue or errors in the history after the fix was applied:
Someone on reddit had already spotted this which drew my attention to the common issue, this only presents itself for workflows with pause steps!
I will update this post with my findings once this latest fix is applied.
Symptom
After applying .NET Security Only patch to resolve CVE-2018-8421 (Remote Code Execution Vulnerability) , all SharePoint out of the box Workflows fail to execute and the log will show an error like this:
09/13/2018 01:59:07.57 w3wp.exe (0x1868) 0x22FC SharePoint Foundation Workflow Infrastructure 72fs Unexpected RunWorkflow: Microsoft.SharePoint.SPException: <Error><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″ Text=”Type System.CodeDom.CodeBinaryOperatorExpression is not marked as authorized in the application configuration file.” /><CompilerError Line=”-1″ Column=”-1″…
The error suggest that System.CodeDom.CodeBinaryOperatorExpression is not in the authorized types.
Cause
Workflow Foundation (WF) will only run workflows when all the dependent types and assemblies are authorized in the .NET config file (or added explicitly via code) under this tree:
<configuration>
<System.Workflow.ComponentModel.WorkflowCompiler>
<authorizedTypes>
<targetFx>
However, after the update, the following lines are necessary for SharePoint 2013 and beyond:
Please notice that sometimes SharePoint Timer Service (SPTimerV4) runs workflows. If you notice that the application showing the error is ULS logs in OWSTIMER.EXE, you should also include the authorized types in [SharePoint Hive Folder]\bin\OWSTIMER.EXE.config. The Hive Folder will change by version of SharePoint. For SharePoint 2016, it is normally at c:\program files\common files\microsoft shared\web server extensions\16. For 2013, at c:\program files\common files\microsoft shared\web server extensions\15.
If you have Nintex workflows you should run like this:
Add-CodeDomAuthorizedType -IncludeNintexWorkflow
To undo the changes, run:
Remove-CodeDomAuthorizedType
The script needs to run only once on any WFE. All web.config files related to SharePoint on all servers will be modified. New web applications created after that will also include the changes. Even if a new WFE is added to the farm, the entries will also be included in web.config. The change is a permanent requirement from now on since the WF patch. You do not need to undo the change before applying the SharePoint patch addressing it.
There is a second script to update OWSTIMER.exe.config. This one should only run if you see the symptoms in ULS logs with process OWSTIMER.EXE. Otherwise, you do not need to update. if you have the problem though, you need to rerun the script if a new machine is added to the farm. No line needs to be uncommented for this one. The script name is:
Microsoft is aware of this issue and patches for SharePoint 2010, 2013 and 2016 are being worked as of 9/17/2018. I will update when we have an ETA. I had confirmation from the product team on 9/18/2018 that this information and solution on this post is in the line with the future patch and it is the recommended action plan until the patch is out. If anything change, I will update the post.
Note 2
Some people using third-party workflows (like Nintex) need to also include this:
SharePoint Stuff 