I had to build a fairly complex workflow not long ago. The workflow was built in SharePoint Designer 2013 and had a lot of moving parts to it. So many, that when I went to publish it I received the following error message: “Microsoft.Workflow.Client.ActivityValidationException: Workflow XAML failed validation due to the following errors: Activity “SomeXActivity” has 65 arguments, which exceeds the maximum number of arguments per activity (50).” This error message is actually telling us that our workflow has too many variables within it. Basically, this is happening because when the workflow is running the Workflow Manager has to manage more 58 (in my case) variables. Workflow Manager only allows there to be 50 variables in the workflow… by default.
Resolving Microsoft.Workflow.Client.ActivityValidationException Exceptions
Really, the easiest way to do this is to review your workflow and determine if you can cut down on the number of variables. This is the first thing I did actually. I was able to cut it down to 58 from about 65 variables. I had so many extras because some of the activities added to a workflow create default variables. However, if you change the variable being used or delete the action entirely it doesn’t remove the default variable. So over the course of creating my workflow, I had a bunch of variables within just doing nothing.
Update the Workflow Configuration
If you have cleaned up your workflow as much as you possibly can and you still have way too many variables the next step is to update the configuration. The 50 argument limitation is a soft limit. Meaning you can go beyond it. Now keep in mind, Microsoft applies these limitations for a reason. If you have a lot of workflows running that exceed the default limits you are going to end up having performance issues. So keep this in mind as you modify the configuration and build future workflows.
I am going to start with what NOT to do. This is actually why I wrote this blog. Every single post I read stated to update the SQL tables directly.
Don’t do it. No seriously don’t. You run the likely risk of voiding any warranty or support from Microsoft if you do this. I didn’t want to do this so I started looking deeper to find out if there was another way we could fix this issue. Enter my very good friend PowerShell
Update the Workflow Configuration…Properly
We are actually going to fix this with the Workflow Manager PowerShell Command Shell. Specifically, we are going to be running the Set-WFServiceConfiguration. You have to run this against the SharePoint Web Application that holds the workflow manager. You can read up on this commandlet here. The basic process I am going to execute via some PowerShell is to update the allowable arguments and for good measure the allowable variables. Once that is done we need to ensure the new values are utilized by restarting the Workflow Service (you need to do this on each of your workflow servers).
Running the following commands will allow you to increase the allowable variables in a workflow:
#Update the variable and argument configurations on the Workflow Manager Set-WFServiceConfiguration -ServiceUri <workflow manager URL> -Name WorkflowServiceMaxVariablesPerActivity -Value 75 Set-WFServiceConfiguration -ServiceUri <workflow manager URL> -Name WorkflowServiceMaxArgumentsPerActivity -Value 75 #Run the following on each server in the Workflow Manager farm net stop workflowservicebackend Stop-WFHost #Ensure everything is stopped properly Get-WFFarmStatus #start services Start-WFHost #check services are running Get-WFFarmStatus
Once you execute these commands you will be good to go without having had touched your database and possibly voiding your warranty.
Thanks for reading!