Workflow class with Start(), Continue(), and Resume() methods
Comments:


The structure and naming of this class says "I am a runner" but it isn't really a runner if it is basically a mechanism to persist and retrieve state. This is especially confounding because you have a separate state class. There's nothing to start, continue, or resume, except storage and retrieval of state from the session. In fact, conceptually, this class is the context, and your WorkflowContext and WorkflowState classes appear to be more appropriate runner objects.
Continue() and Resume()--combine them into one method where you either always pass values, or never pass values. Either the calling class needs to be able to check the session and retrieve values to pass in, or the method needs to be changed to be able to hydrate the session if it hasn't been initialized yet. This class should probably encapsulate direct session access, so I'd go with the latter. Otherwise, calling code has to make assumptions about the session, which is brittle and an encapsulation no-no.
All void methods and a ton of properties. This class exposes a lot of objects, and more specifically, objects that this class internally initializes. This makes your void methods stateful and full of side effects. If you are using this class to basically initialize and hold a bag of properties that you then access in business logic, why not make your methods stateless by returning a state object from this method? The current class is not really suited to be both the state (session) AND the state-getter. It would be much better to move the properties on this class to a separate state object, and change this class to have CreateNewSession() and GetExistingSession() methods that then return a state object. You can probably combine that state object with your other classes, too. Again, do ensure nothing external can assume anything about the application session.