powershell workflow

I have recently been working with the Microsoft Azure Pack and more specifically, SMA. SMA heavily relies on PowerShell Workflows. This was a great opportuniy for me to refresh my workflow knowledge. I have documented here under the most common things that you need to know when you are working with PowerShell workflows.

A PowerShell workflow is the Powershell implementation of the WWF (Windows workflow FrameWork). It brings a cool set of functionalities such as the possibilities to execute code in parallel, to create scripts that are persist to reboot, and lot’s of other neat things.

Using Powershell Workflow is a piece of cake when you have already powershell scripting skills. PowerShell workflow is available from Powershell version 3.0 up to version 5.0 (Or should I say ‘since’ version 3.0?). Have you ever written a Function ?Then you already know how to write a PowerShell workflow.

PowerShell workflows: the basics

The most basic (ever) workflow would be written like in the example here below:


Other keywords will need to be used in it, but you have here the basics of a workflow. You are probably wondering why I asked if you already wrote a function using PowerShell ? Well, simply because you can leverage that same knowledge in order to create Workflows. You saw how simple it was to create an empty workflow. You can add to that all your existing knowledge of the Advanced Parameters that you have acquired during all these hard years of scripting, and use them directly in your workflows for some advanced parameter validation.

Like I said above, the power of workflows is really released when you use the correct key words. Here are a few that you should remember:

  • PsPersist
  • Parallelism
    • Parallel
    • Foreach -Parallel
  • Sequence
  • InlineScript

Also, workflows have particular scoping possibilities.

  • $Using
  • $Workflow

Let’s go through them, and see which possibilities they offer us:

WorkFlow CheckPoints:

One really cool thing about a workflow is that it can be “persistent”. this means, that It can survive things such as reboots, network disruptions etc…

We already know that a workflow is actually a set of independent activies running one after each other. It is possible to make a workflow resiliant either after one specefic activty, or directly once the workflow is started.

The two ways of doing this are the following ones:

  • PsPersist
  • Checkpoint-Workflow

Bear in mind that using a Checkpoint is great because it makes you script persistant, but remember that you have signed a pact with the  “duration devil“. Using this feature will allow you to make your script persistent, yes! But only in exchange of lowering your performance results.


The PsPersist term isn’t actually really a keyword that you use inside a workflow. It is a common parameter that you add to the call of your workflow. Something similar to the -verbose of normal function or any PowerShell cmdlet.

This is the parameter that you would like to add to your workflow if you know that your workflow will face reboots. This will make it “persistent” and it will be able to overcome reboots.

-Persist is a parameter that allows your workflows to be resiliant to reboots. This parameter is available to any powershell workflow since it is part of the common set of workflow parameters.



The checkPoint-workflow is a quite handy cmdlet. Indeed, it allows to make the workflow persist very easily. Why that ? well simply because you write it (almost) anywhere in the workflow, and it will do the a check point for you.

I personnaly like to put a CheckPoint-Workflow after a part that might have taken a long time to run.  (Specefically in  an InlineScript block).

In order to call a CheckPoint-Workflow, simply add it anywhere you would like in you script (Except in an inlineScript!).


In the example above, I have adapted a workflow I once wrote in order to show where I would set the CheckPoint-Workflow. Indeed, I have set it there, because the PostConfig.ps1 script is a heavy script that would set specefic registry keys, copy files, install BGinfo etc… It would also send back an object with values specefic to the server it has been executed that I can then re-use later on in my workflow for deeper automation.

keep in mind that CheckPoint-Workflow cannot be put in an InlineScript section.


(Parallelism is actuall not a keyword, but a concept that englobes two key words.)
By default, PowerShell Workflows (and scripts, functions etc..) only work sequencialy. This means that each command of a workflow (called activity) will be run one after another. PowerShell workflow brings a new dimension to this by introducing the concept of Parallelism.

The Parallelism functionnality can be used with two different keywords:

  • Parallel
  • Foreach -parallel


The parrallel key word will allow to specify a block of code that needs to be run in parallel.


Foreach -parallel

Foreach -parallel will do exactly what is says it does: It will do tasks in parallel. It work just like the good old Foreach construct that we all know by now, but it will call the different elements from the array in parallel in stead of one by one.

The example below for a more real life example:

(only works in workflows)

Unfortunatley, Foreach -Parallel only works in Workflows.


The sequence command allow to run activities sequencialy. This means that activities will be run one after each other.

But wait! Aren’t  workflows already supposed to be working sequentially? That is correct! But they become extremly helpfull when used in a parallel block, because we could want to call one activity in the parallel script block which actually has to respect a certain order (like the installation of prerequisites prior the installation of an application for instance).

Again, Sequence is only allowed in a PowerShell WorkFlow.

Sequences should be consired as independant blocks. Avoid trying to get data back from it.


Not everything will work as straight forward in PowerShell workflows as when you PowerShell functions, or scripts etc..
Why that?

Well, for a workflow to become a real workflow, it is converted to WWF. And not any powershell command cannot be converted to WWF unfortunatley.

But not worries, we have an alternative. We have “inlineScript”.

Indeed, “inlineScript” Let’s you use any powershell command. Not just the one that can be converted to WWF.

And inline script section is executed as one and single unit, and, one very important point is that the InlineScript has it’s own scope.

$Workflow scope cannot be used in InlineScript. Must use $Using

$Using: –> Use this in order to be able to access variables that have been declared in the $workflow scope.


So, now that we have started to talk a little bit about scoping, let’s get a bit more into the details.

Two elements should be kept in mind here:

$Using: –> use this when writing “inlineScript” parts. Using the “$Using” scoping variable will allow you like this for this example of the variable $Path which would have been declared previously:

The following code will NOT work

The $Using:Path will tell the inlineScript section to get the variable value in the scope above.


As decribed above, there are actually two different scopes:

  • $workflow

This scope is as it’s name says global to the complete workflow. Anything declared under this scope will only be available through that scope.

  • $Using

as explained above, the “inlineScript{}” section allows you tu use powershell code and cmdlets that would not be permitted in a normal section of a workflow. It is possible to use a variable that has been declared in the $workflow scope using the keyword “$using:NameOfYourVariable”.

For example, you  have a variable called $ScriptPath in your workflow, and you want to you use the value of that same variable in you “inlineScript” section. You would do it like this:

The example is very simplified, just to make the understanding more easy. Here we have access to the $ScriptPath Value simply by using the keyword $using:ScriptPath


Workflow variables –> http://technet.microsoft.com/fr-fr/library/jj574187.aspx

PowerShell Magazine article –> http://www.powershellmagazine.com/2012/11/14/powershell-workflows/

Output information in SMA Azure pack –> http://blogs.technet.com/b/orchestrator/archive/2014/01/16/sma-capabilities-in-depth-controlling-runbook-streams-for-testing-and-troubleshooting.aspx

By | 2016-10-19T21:00:15+00:00 November 5th, 2014|PowerShell, Workflow|11 Comments

About the Author:

Stéphane is a dynamic and passionate Cloud and datacenter Microsoft MVP since. He is the founder of the Basel PowerShell user Group (BPUG), the co-founder of the French Speaking PowerShell UserGroup (FRPSUG), author, blogger, and received the community award "PowerShell Hero" from PowerShell.org. Stéphane has implemented microsoft infrastructure solutions in various countries of Europe and is currently working in Basel / Switzerland. Stéphane help his clients to reduce their global infrastructure costs by implementing Microsft infrastructure solutions by combining great products such as System Center, Windows Server, with heavy automation using Windows PowerShell. Stéphane loves languages, Belgium beer, French cheese and French Wine. If any of these topics are of your interest, don't hesitate to come and say hi.


  1. Raith Munro November 19, 2017 at 12:39 am - Reply

    “PowerShell workflow is available from Powershell version 3.0 up to version 5.0 (Or should I say ‘since’ version 3.0?)”

    No, you were right the first time – up to version 5.0.

    Workflow is not supported in the new Powershell Core (6.0) as WWF is not part of .NET Standard.

  2. Veljko Grubacic December 20, 2016 at 8:51 am - Reply


  3. rv August 22, 2016 at 7:31 pm - Reply

    Thanks for sharing this information!!
    Good info for a beginner. Info is clear, detailed and examples make it easier to understand.

  4. Shabuddin Khan July 21, 2016 at 4:37 pm - Reply

    Stephane – Thanks.. to the point.. and explains well. You just taught me how to work with workflows.. Kudos and thanks.. 🙂

  5. Rudenco Victor March 20, 2016 at 8:33 am - Reply

    Very clear and easy to understand explanation of Powershell workflow concept. Good step to mention also additional links. Thank Stephane. Seing a real Hero.

    • Stephane March 20, 2016 at 8:55 am - Reply

      Thanks victor for your nice words :). I am happy it could help

  6. Charles October 14, 2015 at 8:32 am - Reply

    Good one! crisp and precise explanation. I have a dumb query. I am running the above given workflows as script in PS 4.0 still not getting the output. No error either. It is not taking input for any of the param specified. what could be the reason?!

    • svangulick October 14, 2015 at 10:49 am - Reply

      Hi Charles,

      Thanks for the nice words 🙂

      This is a normal behavior. Workflows work like functions. First you need to load them into memory, then you call them to retrieve the information.
      For the example of this post, you will first execute the workflow (thus, load into memory) and then execute it by calling it again like this:


      The value located in $ScriptPath must be a location existing in your environment of course.

      You can then call the script using the -ScriptPath parameter to set another value then the default one.

      Run-ThisScript -ScriptPath C:\MyFolder

      Hope this helps.


      • Charles October 15, 2015 at 8:15 am - Reply

        Thanks mate! It works.

  7. Chris July 21, 2015 at 3:33 pm - Reply

    nice, very neat feature I wasn’t aware of.. Very clear explanation, thanks a lot, will start playing with it.

  8. vardhan January 8, 2015 at 4:59 am - Reply

    Thanks !!!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: