In a previous post I mentioned that I’d discuss the three types of workflow you can implement with Workflow Foundation so here it is.  I also mention how I implemented them and where.


A sequential workflow represents a workflow as a procession of steps that execute in order until the last activity completes.

However sequential workflows are not purely sequential in their execution. They can receive external events, include parallel logic flows and the exact order of activity execution can vary somewhat.  You can leverage correlation to resume a workflow that was previously suspended.  I cover correlation in one of my earlier posts.


Where did I use them and why?

I have typically used sequential workflows in conjunction with a Receive and Send Code Activity.

The inner logic of the workflow was responsible for intense number crunching.  The workflow received a data contract with specific properties which were used in calculations to determine scores against an individual.

The workflow then sent calculated scores to other modules of an enterprise application.  Front-end developers didn’t have to concern themselves with the underlying calculations.  They only had data contract properties to the UI elements.

The client wanted to be able to configure various steps of this “top to bottom” process when new legislative bills were passed and to update how the overall scoring was arrived it.  The sequential workflow was perfect as the scoring process ran from top to bottom.

State Machine

Unlike Sequential Workflows which are linear, State Machines are much more flexible and have an event-guided execution model.  The State Machine Workflow is modelled as a collection of discrete named states, having one active state at a time. These states can contain one or more activities and contain the following basic elements:

A finite list of the possible states the state machine can be in.

States include a collection of Transitions.  A Transition defines the movement from a source State to a destination State.

Each Transition is configured with a Trigger Activity, typically an event driven Activity such as Receive Message.  A user can also specify an expression as the Condition of a transition.

Final State
A State which upon reaching it will terminate the State Machine.  A basic scenario that can demonstrate a State Machine is a stop watch, detailed below:


This State Machine has four possible states:

  • On– initial state of the stopwatch, no data is displayed
  • Started – the stopwatch internal clock is started and the display is updated every 10 milliseconds.
  • Stopped – the stopwatch internal clock is stopped and the display shows its last value.
  • Off – the stopwatch is powered off. It is a final state in this stop watch model.

It features five possible Transitions (Start Clock, Start Clock, Stop Clock, Turn Off, Turn Off) between each State.

As mentioned earlier, a State Machine can have Conditions.  A Condition in the context of the above example may be the “Turn Off” condition.  It could verify that the Stopwatch objects current State is not already set to “Off” before attempting to Transition to the “Off” State.

Where did I use the State Machine and why?

I had to build a strict approvals process where the status_id of records could only be progressed from one level to the next via specific roles with accompanying conditions.

Could this have been done in regular C# code? 

Yes, but it wouldn’t have been as configurable and the sea of logic wouldn’t be very readable to the user.

Worth mentioning that I also had to persist these state machines in the database as these processes were more than likely going to be long running.  This was achievable by implementing persistence.

Persistence deserves its own post so I’ll cover that in the future!

Flowchart Workflows

These are probably my favourite types of workflow to build.


They are more aligned with how people visualise workflows and are very intuitive to read and build. One downside however is the designer canvas can get cluttered very quickly.  The solution to this is to break down your workflows into discrete blocks on logic.

Here we can see a sample flow chart workflow.  It has an entry point, a Code Activity that performs an assignment, there is a decision process too modelled by the Flow Decision Code Activity.  You can see the Boolean logic in the top right (if myStr = “Hello”).

Depending on the value of mStr, the text “In True Branch” or “In False Branch” will be displayed.

In some ways, these are like sequential workflows in that they run down a specific path, i.e. from the entry point until they reach the end.

Where did I use them and why?

When I felt there were lots of “moving parts” and I had requirements that consisted of sequential workflows, state machines and flow charts within flow charts.


I put together a checklist to remind me of common things to look for when trying to decide which type of workflow I should be implementing.  There are often multiple solutions to any given business problem and each use case should be judged on its own merits and this list isn’t exhaustive.

Sequential Workflow Guidelines

  1. Does the use case result in the output of a value/object or collection of values/objects?
  2. Can the use case be invoked via a trigger in either from the application front-end or external system?
  3. Can the process flow presented in the use case be easily mapped to discrete blocks / fine grained system requirements in an end to end fashion?
  4. Leading onto, does the use case have clear, well defined inputs / outputs being passed between each step?
  5. Does the use case have a finite number of steps in the process and is run from beginning to end without any intervention?
  6. The use case runs from start to finish with no delays.
  7. The use case does not follow record(s) through a one or many transitions.
  8. Does the use case need to support a dashboard or queue? If so, Workflow Foundation Tracking can be considered.  Variables to track should be identified.
  9. Is the use case potentially long running? If so, Workflow Foundation Persistence must be implemented. (For long running processes a State Machine is generally the better option)
  10. Does your workflow include many sequential processes with not much human interactivity?

State Machine Workflow Guidelines

  1. Is there a common business object being passed between one or more use cases in the functional specification document?
  2. If a common business object has been identified, does a property or collection of properties get progressed through a series of States / values in the use case?
  3. From #2, what is the Initial State?
  4. From #2, what is the Completed State?
  5. What are the triggers responsible for progressing the business object through the States identified in steps #2-4? These form Transitions.  For example, an approval process that is driven from external actions.
  6. Do the Transitions have Conditions applied to them? For example, a User invoking the Transition may have to belong to a certain Role, otherwise the State Machine should not permit the Transition.
  7. Does the use case need to support a dashboard or queue? If so, Workflow Foundation Tracking can be considered.  Variables to track should be identified.
  8. Is the use case potentially long running? If so, Persistence must be implemented.
  9. If your workflow is totally dependent on the human interaction?
Get the latest content and code from the blog posts!
I respect your privacy. No spam. Ever.