I had an issue that I discovered yesterday where a few of my workflows were getting stuck in the suspended state. I had to do a ton of testing to figure out that it was the 'Create Alerts' role permission that had to be added to the site for the workflow initiators. The error message on the workflow was an access denied error when trying to hit the /_api/sp.utility.sendemail service.
I recreated this problem in multiple site collections, and it's my view that something changed on the back end that caused my workflows to suddenly stop working. Here's how to set it up:
- Create a custom list, add a user field
- Create a quick SP2013 Designer Workflow that sends an email to the user in the user field (I don't think it matters who you send an email to)
- Make sure the list has unique permissions. Give your test user Edit permissions to the list
- Give the test user only read permissions to the site. The 'create alert' permission is not included in the read role by default.
- Have your test user run the workflow. It will get stuck on the send email action.
- Then enable the 'create alerts' permission on the read role for that site
- rerun the workflow, and it will work.
This was not broken before Tuesday, but all my workflows where users only have read permissions to the site but edit permissions to the list got stuck on the send email activity. This caused a lot of stress and confusion, and it was by nothing that I changed. These workflows have been running for over a year, with only the occasional hang up.
I would really like it if someone could confirm this, and if Microsoft would confirm this as a bug. I do not want to enabled the create alerts permission for all of my readonly users that might have to run a workflow on a specific list.
