Workflow failed on start (retrying) when anonymous users start workflows

Here is an interesting issue and subsequent workaround – anonymous users can create list items (if granted the appropriate permissions), but workflows will not start for anonymous users.

If you do some research on this topic, you’ll see lots of people trying to allow this, so that emails can be sent for example – but the answer is almost always “here is some code you can deploy.” That’s an unfortunate answer, as not all of us have the ability or skillset to write and deploy Visual Studio code to our environments or our client’s environments.

However, after lots of trial and error I came up with a solution using PowerShell.

Essentially, we need to do the following:

  1. Grant anonymous users the ability to add items
  2. Setup a SharePoint Designer workflow to do the e-mailing, or what have you – set the workflow to start when items are changed, not when items are created…
  3. Configure a PowerShell script to run against the site or sites so that the items get updated if they have not yet had their Workflow Status updated to “Complete”

The script is currently configured to iterate through a single site collection and all of it’s subwebs, looking for any “GenericList” (Custom List) that has items which have not yet been marked as “Completed” by the workflow engine…

Here is my PowerShell Script to update items:

Start-SPAssignment -Global
$Site = Get-SPSite http://siteurl
$Webs = $Site.AllWebs
	foreach ($Web in $Webs) {
		foreach ($list in $Web.Lists | where {$_.BaseType -eq "GenericList"}){
			foreach ($item in $list.Items | where {$_.Workflows.InternalState -ne "Completed"}) {
Stop-SPAssignment -Global

Setup a Windows Scheduled Task to run this every half-hour or so, and it will iterate through your site – kicking off any yet-to-be-started workflows under the context of whatever account you use in the Scheduled Task.

Disclaimer: This may cause heavy utilization of server resources if you have a large site collection, lots of lists, big lists, or if you run this against multiple web applications. I’m sure there are other (perhaps better) solutions, but this works for me. No warranty or guarantee is implied. 🙂



8 thoughts on “Workflow failed on start (retrying) when anonymous users start workflows

  1. Brian T. Jackett (@BrianTJackett)

    I like the concept. One suggestion. In an attempt to make a more “SharePoint contained” solution I propose creating a custom SharePoint timer job that runs the same type of code listed and running on a defined schedule. That way if the server hosting the scheduled task is down the timer job “should” be running on another server. I know that goes into deploying code and the associated overhead, but feels a bit more enterprise ready.

    -Brian T. Jackett

    • Ryan Dennis


      Thanks for the comment. I agree, I think a custom timer job would be a great idea and as you said, would be more enterprise ready – but for small scale or POC purposes, this seems to work pretty well.


  2. workflowssuck

    So does this still work on the latest patch of 2010 sharepoint? Because we just upgraded the site, and while it does modify the list item’s “last modified” property with the name of the windows user running the task, and the time the task was run, the workflow does not actually trigger anymore (on change, you would think changing the “last modified” property is a change, but maybe not anymore???). I believe my current version is 14.0.6029.1000 but its hard to figure out where the version number actually is. God I hate sharepoint 😦

    • Ryan Dennis

      I have not tested this on the latest about SharePoint, but I don’t know of any Object Model changes that would affect the execution. Are you running this as a “System Account”? I don’t believe workflows will start when running under the context of system account, you may need to run it with some sort of ‘real’ user… Hope this helps!

      • workflowssuck

        Sorry i think it was actually my bad. I am now just having some weirdness with powershell, or I didnt wait long enough. Manually running the script is fine (although seems to take 4 minutes or so after running the script for the workflow to start) so it must be something with how i am running it using powershell, which shouldnt have changed after the update but I can easily work on that.

        Its just strange though, because all along the date modified and user modified properties were being updated by the script successfully. Infact even now, running the script by first starting powershell and then running the script like ./SCRIPT.ps1 , works fine, changes the name and modified date and after about 4 minutes, triggers the workflow.

        However using “powershell.exe -command “&’script.ps1′” ” OR “powershell.exe -file ‘script.ps1′” and then referencing the script, updates the name and modified by but DOES NOT trigger the on changed work order to run. This inconsistency made me initially blame your script.

        its strange that it would still run, yet behave inconsistently between running it in power shell and calling powershell from CMD.exe. Both are the same user, and one would think the same exact powershell. Something else fishy is going on, and with sharepoint, that is generally the case i find!

        anyways ill post back if i figure it out, however its most likely a powershell thing.

        oh btw, i did add “Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue” as line 1 of your script so that the sharepoint stuff is loaded into powershell before it starts trying to run it. And it worked last week, so hopefully i can fix it!

  3. Matthew Thomas

    One thing i want to note on this is that if you allow anonymous users the ability to add items, SP automatically give anonymous view as well. So far, without code i havent been able to figure out how to allow add with no view.

  4. workflowssuck

    I think my solution was to give the anon’s a view with a conditon that cant possibly be matched, so the view always returns nothing. In my case, they are redirected to a different static page when they submit the form, not the list page. And if they do puzzle out how to get to the list page (by editing the url and knowing sharepoint enough) they will be presented with a list page with only one view and that view doesnt let them see anything. A bit of a hack and security by obscurity, however i take the items from that list by workflow and move them to another secure list 5 minutes after they are submitted.

    Sharepoint = a bunch of hacks!

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s