SharePoint Workflow Fails & Dead-Simple Fixes

Most admins treat SharePoint Workflow Manager like a black box. They see an error, panic, and start blindly tweaking server settings.

It never works. You cannot just guess your way through legacy Microsoft infrastructure. You have to fix the root cause. Here are the five most common ways SharePoint 2013 workflows will break your heart and exactly how to fix them.

First up is the basic communication failure. You followed the installation docs perfectly. You used a Fully Qualified Domain Name because that is what server admins do. Then the workflow service refuses to talk. The hard truth is that FQDNs often break this specific setup. You need to strip it out. Reinstall the workflow manager using just the short server name alongside the Service Bus 1.0 cumulative update 1. If you need the baseline reference for this process, read the http://technet.microsoft.com/en-us/library/jj193448 guide.

Then you have the registration errors. You build a workflow in Designer. You hit publish. The server spits back an error saying your scope is "Unregistered". The workflow is not broken. Your registration is just out of sync. You fix this by forcing a reconnection via PowerShell. Run Register-SPWorkflowService with the -Force and -ScopeName "SharePoint" parameters against your site http:// SP2013DEV01/ and host http:// SP2013DEV01/:12291/.

Sometimes the workflow publishes fine but immediately suspends itself. You check the info icon and see nothing but generic failure codes. The fix is almost identical to the unregistered scope issue. You just need to add one parameter to allow HTTP. Run the registration command again for http:// SP2013DEV01/ and http:// SP2013DEV01/:12291/ but make sure to include -AllowOAuthHttp.

Next is the silent killer. Your workflows are automatically cancelling. You dig into the logs and find a 401 exception complaining that the token contains an invalid signature. I see admins spend days trying to rebuild their entire certificate trust. Do not do that. It is a known sync issue. Just go to Central Administration and manually run the "Trusted Security Token Services Metadata feed" timer job.

Finally, the classic staging crash. Your workflow runs perfectly in development. You deploy the solution to staging and it instantly throws an ActivityValidationException about an unknown type.

Here is what actually happened. Visual Studio 2012 quietly slips a specific design time DLL into your project.

That file is Microsoft.SharePoint.DesignTime.Activities.dll. Your dev server has Visual Studio installed, so it finds the file in the PublicAssemblies folder. Your staging server does not. The solution is boring but effective. Drop that DLL directly into your inetpub/_app_bin folder and reference it in your project.

Stop guessing. Keep a checklist. Fix the fundamentals.