SharePoint 2010 Workflow Features Not Available in the SharePoint 2013 Workflow Platform

With the new workflow infrastructure in SharePoint 2013, some actions, conditions and blocks that were available in SharePoint 2010 are only available in 2013 when using the SharePoint workflow interop. The following features below are available only on the SharePoint 2010 Workflow platform (source).


  • Stop Workflow
  • Capture a Version of the Document Set
  • Send Document Set to Repository
  • Set Content Approval Status for the Document Set
  • Start Document Set Approval Process
  • Declare Record
  • Set Content Approval Status
  • Undeclare Record
  • Add List Item
  • Inherit List Item Parent Permissions
  • Remove List Item Permissions
  • Replace List Item Permissions
  • Lookup Manager of a User
  • Assign a Form to a Group
  • Assign a To-Do Item
  • Collect Data from a User
  • Start Approval Process
  • Start Custom Task Process
  • Start Feedback Process
  • Copy List Item (SP Designer 2013 supports only the document-copying action)


  • If current item field equals value
  • If current item field equals value
  • Check list item permission levels
  • Check list item permissions


  • Impersonation block

Data Sources:

  • User Profile lookup

Other features:

  • Visio integration
  • Association Column
  • Content Type Association for reusable workflow
  • ‘Require Manage List/Web Permission’ feature for list/site workflow
  • Globally reusable workflow type
  • Workflow visualization option

To see how to still use these features in SharePoint Designer 2013, check out my Create a 2010 Workflow In SharePoint Designer 2013 post.

Create a 2010 Workflow in SharePoint Designer 2013

In this post I am going to walk through how to create a 2010 workflow in SharePoint Designer 2013 that changes the list item permissions. I will show how to call a SharePoint Designer 2010 workflow from a SharePoint Designer 2013 workflow in a future post.

1. Start SharePoint Designer 2013

2. Navigate to the list or library that you would like to have this workflow associated to

3. In the ‘Workflows’ section of the list information, click New


4. Enter a name and description for the workflow and change the ‘Platform Type’ to SharePoint 2010 Workflow.


6. Rename ‘Step 1’ step container to ‘Start of Workflow’.

7. Add a ‘Log to History List’ action item. – Logging is helpful for times when you need to troubleshoot

8. Click on the ‘this message’ link in the ‘Log to History List’ action item


9. Add a message similar to ‘Update Item Permissions workflow starting…’

10. Click outside of the first step box so that the ‘Impersonation Step’ button becomes active on the ribbon.

11. Click the ‘Impersonation Step’ button on the ribbon.


12. Add the appropriate permissions steps. If you need to remove permissions, use the ‘Remove List Item Permissions’ action. If you need to add permissions, use the ‘Add List Item Permissions’ action. For my example, I am going to remove permissions from the current item that was just created.

13. Click on the ‘these permissions’ link on the ‘Remove List Item Permissions’ action.


14. In the ‘Remove List Item Permissions’ dialog box, click Add.


15. Select the users/groups that need to have their permissions removed by clicking on the ‘Choose…’ button.


16. Select the users/groups that need their permissions removed. To access list the people and groups that currently have access to the SharePoint select the ‘People/Groups from SharePoint site..’ then click Add.


17. A new dialog box will appear to allow you to search for the people/groups. Select the user that needs to have their permissions removed.


18. Select OK and OK again on the Select Users dialog box


19. In the permissions dialog box, choose what permissions need to be removed. In my example, ‘Contribute’ permissions need to be removed. Then select OK


20. Select OK again on the ‘Remove List Item Permissions’ dialog box.


21. Click on the ‘this list’ link in the ‘Remove List Item Permissions’ action.


22. In the Choose List Item dialog box, select ‘Current Item’ and then select OK


23. Add another log after your ‘Remove List Item Permissions’ action to save you some time when troubleshooting in the future.


24. Check for Errors

25. Publish


26. You will be prompted by the message shown below, click OK


That’s it! Pretty simple, right?

SharePoint 2013 Workflow Cancels Automatically

I had been dealing with an issue for a few days and after figuring out the solution I have decided to try to save someone else from having the headache I had to deal with. The issue was that simple SharePoint 2013 workflows created with SP Designer would cancel automatically with an internal status of ‘Canceled’ while SharePoint 2010 workflows worked just as expected. The following error was provided (which didn’t seem very helpful at first):

RequestorId: 8be6fbda-d14b-1182-54ee-f8b57cbd6f59. Details: System.ApplicationException: HTTP 401 {“Transfer-Encoding”:[“chunked”],”X-SharePointHealthScore”:[“0″],”SPClientServiceRequestDuration”:[“47″],”SPRequestGuid”:[“8be6fbda-d14b-1182-54ee-f8b57cbd6f59″],”request-id”:[“8be6fbda-d14b-1182-54ee-f8b57cbd6f59″],”X-FRAME-OPTIONS”:[“SAMEORIGIN”],”X-Content-Type-Options”:[“nosniff”],”X-MS-InvokeApp”:[“1; RequireReadOnly”],”MicrosoftSharePointTeamServices”:[“″],”Cache-Control”:[“max-age=0, private”],”Date”:[“Mon, 17 Feb 2014 21:03:02 GMT”],”WWW-Authenticate”:[“NTLM”],”X-AspNet-Version”:[“4.0.30319″],”X-Powered-By”:[“ASP.NET”]} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Also, if that user tried viewing the workflow status they would receive a ‘Sorry, you don’t have access to this page.’

The few posts that I came across when researching this issue mentioned granting users edit access at the site level. This did fix the issue but it did not seem like a reasonable solution for me so I did a little more investigating. Turns out that with the new changes to the SharePoint 2013 workflow, there was also changes made to which account is used to write logs to the Workflow History list. In 2010 the system admin account was used but in 2013 the workflow initiator’s account is used. This account needs to have at least contribute permissions to the Workflow History list (a hidden list that can be accessed through SP Designer). So here’s my solution:

  1. Navigate to the site that the workflow is on in SharePoint 2013 Designer.
  2. Go to All Files -> Lists
  3. Right click on Workflow History
  4. Select Properties
  5. Click on Permissions for this list under the ‘Customization’ section (This should open up the edit permissions page in the browser)
  6. Break inheritance on this list by selecting Stop Inheriting Permissions in the new opened browser window
  7. Use the check box next to the appropriate group (probably the visitors group) to select the group that needs updated permissions
  8. Select Edit User Permissions
  9. Grant the group ‘Contribute’ permissions
  10. Select OK

Also, it is important to note that if a task is being created in a task list the account will also need access to write to the task list.