Settings in custom Umbraco forms workflows

As you may or may not know, Umbraco Forms, like the Umbraco CMS, is highly extensible. One of the things you can do with it is create your own custom "types", be it field types, export types, or in my case recently a Workflow type.

Now, I'll start this with a caveat - I was doing this for Umbraco Forms v8 and I've not tested if the behaviour is the same for newer netcore versions of Umbraco Forms ... But!

If you are adding custom settings to your custom workflow, which I would imagine you are, they must be string properties. No matter what the data they are storing is, the property on the Workflow class must be a string.

public class MyCustomWorkflow : WorkflowType
{
       [Setting /* Attribute values omitted for brevity */]
       public string MyCustomSetting { get; set; }

       //Additional code omitted for brevity
}

How did I find this out you ask?

Well, on the workflow I was creating I was trying to store a Guid which was the result of a dropdown selection. My property was set as a Guid type instead of a string.

Things all looked good, the workflow showed in the CMS, I was able to select it when adding a workflow, but this was as far as I got. When trying to Save the workflow nothing happened, the dialogue wouldn't close but no error was shown.

Dev tools to the rescue --- kind of.

Dev tools allowed me to see that an API request was returning a 500 response.

This exception was... System.MissingMethodException and it referenced the name of the property for my setting to be stored in. This confused me for the best part of an hour I think, I tried all sorts of combinations but every time the same error would be thrown. After studying the stack trace, it showed that this was happening in a method called LoadSettings on the abstract WorkflowType class that all workflows inherit from. A bit of further digging and it's clear that this method is using reflection to try and set the properties and it is this behaviour that, I think, causes the limitation.

Because of this limitation, your implementation of the ValidateSettings method is critical to the operation of your workflow if it has settings on it. This is the point at which you should validate that the string data can be parsed correctly into the actual type you want your setting data to be (even though the property is a string).

I hope this little snippet helps someone when they come across the same problem!