We at Slater Hill Inc recently came across an issue with a customer who wrote Powershell scripts to automate the deployment of a Workflow 2013 for SharePoint solution (including Site Columns, Workflows with complex Task Forms, Constants, and so on).

I have read about (and experienced myself) the problem of automatically publishing a Workflow from an exported NWF file (using the Nintex workflow web service, with or without Powershell) and finding the workflow in the Unpublished state at the destination. The most common cause, according to the community, is a problem with the Columns on the List hosting the workflow.

In our case, however, all of the scriptically-deployed Site Columns appeared to be in place and working fine. We opened the Workflow in the designer and went over it with a fine-toothed comb, removing suspect Actions, reimporting Task Forms from the DEV environment, fiddling with the Workflow Properties -- no luck. Trying to publish the workflow would result in the dreaded "SoapServerException: An error occurred".

We checked available disk space on the SQL Server in case that was the culprit: no dice.

We stumbled upon the cause of the problem when I attempted to modify the default View of the SharePoint List. This resulted in a "Something went wrong" error, which we looked up in the ULS log: "Column 'WorkflowName' could not be found".

So that was the culprit:  the special SharePoint Workflow Status Column that Nintex Workflows insert into the List to show a link (labeled "In Progress", "Completed", etc.) to the status page for the most recent instance of that workflow. At some point in the running of the deployment scripts, this column had been created (perhaps on the failed publish attempt), but then deleted.

The quick and dirty way to resolve this:  we renamed the workflow, which resulted in the insertion of a Status Column with a new name, bypassing the missing column. We still had to create a new default View for our list, though.