header image

Workflows: 1 Introduction

Posted by: | June 18, 2014 | No Comment |

In a recent post I asked for areas of PowerShell that caused problems. Workflows were one of the things mentioned so I’ll start with a series of posts on that topic.


Workflows were introduced to PowerShell in version 3.0 of the Windows Management Framework with Windows 8/2012. A few changes have been made in version 4.0 of WMF (Windows 8.1/2012 R2).

On the surface workflow brings a number of interesting, and potentially very useful, aspects to PowerShell including:

– parallel execution

– ability to survive a reboot of remote or local machine

– ability to checkpoint the workflow and restart at that point

– your task is long running

– your task needs to be run asynchronously

– your task needs to be run on multiple devices

In reality these aims can be met without using workflows. You can use background jobs, multiple instances of a PowerShell script, remoting, scheduled jobs etc to run your tasks. One thing that workflows are good at though is surviving reboots.


Since the flurry of activity that marked their introduction there hasn’t been a lot of noise about workflows. I think that one of the reasons is that they are perceived to be too hard. Workflows look like PowerShell but are subtly different  – they aren’t actually PowerShell even though they use the same syntax. We’ll delve into what they are under the covers in a future post. For now they look like PowerShell and do stuff for us.


Here’s the world’s simplest workflow:

workflow ourfirstworkflow {
  "PowerShell rocks"



if you’re looking at that and thinking it looks like a PowerShell function you’d be right. Swap the workflow key word out for function and you get

function ourfirstworkflow {
  "PowerShell rocks"



Try running the workflow and the function. The function returns the string almost instantaneously. The workflow needs to build the workflow functions in the background before it can run. Any subsequent runs use the “compiled” (its not a true compile but the term serves for what’s happening) workflow and run just about as quick as the function.


One way to achieve parallelism in a work flow is to use the –parallel option on a foreach loop. This is especially useful for accessing a set of remote computers. For now though we’ll keep it simple

workflow alittlebitofparrallel {
param (

foreach -parallel ($number in $numbers)
   "I am number $number"


alittlebitofparrallel -numbers (1..10)


The statement[s] within the foreach loop are run sequentially but the loop is run in parallel for all numbers. Just inputting 1..10 give these results on my machine:

I am number 10
I am number 9
I am number 8
I am number 7
I am number 6
I am number 5
I am number 4
I am number 3
I am number 2
I am number 1


However if you call the workflow with 100 numbers:

alittlebitofparrallel -numbers (1..100)


You will see some evidence of parallelism at work towards the bottom of the results. My test showed this as part of the output

I am number 45
I am number 43
I am number 11
I am number 8
I am number 14
I am number 51
I am number 49
I am number 52
I am number 48
I am number 46
I am number 10
I am number 7
I am number 47


This shows a very important result – the way parallel processing returns results is random-ish. If you need your results back in a predictable manner – parallel execution in a workflow is not what you want to be doing.


I’ll leave it there for now and next time we’ll look at another way to use parallelism and a way to force sequential activities when that is what you really need.

if you want some more workflow related reading try the help files


under: PowerShell V3, PowerShell v4