Using Workflow only for "foreach -parallel"


Until now I haven’t really used Workflows all that much - I however understand what one can do with workflows (or so I think).

My question is, how beneficial is it to write a workflow that does very few different things just the get the functionallity of Foreach -prallel?

As an example, I’m currently about to change attributes on every single user-object in our Active Directory.

Since I obviously can’t test setting any attributes for benchmarking, instead I’ve been getting attributes - figuring if Foreach -parallel was in fact going to give me any benefits, it would show while getting data as well.

However when I compare just, grabbing all the user-objects and then throw them into a simple foreach-loop getting info about every single object vs doing the same but using a workflow with Foreach -prallel - the workflow method actually performs much worse.

Perhaps there is not much point in using Workflows for simple things like this?

Hi Erik,

“My 2 cents”.

Check out jobs and runspaces (PoshRSJob module) to run simple things in parallel. Use workflows for long running processes like building multiple development environments at the same time.

Long answer:
I believe workflows work best for long running processes like orchestrating the build of multiple test environment with many tiers at the same time. Another ability which you won’t get for free with the usual PowerShell scripts is checkpoint and resume. You can set checkpoints in your workflow to preserve the content of variables, suspend the workflow if some happened (e.g. out of disk space or approval required) and resume once resolved without restarting from scratch.

Another advantage of workflows is that you can run them on many machines at the same time. Like doing a ping test, TCP port check or load test from dozens of machines to remote destinations.

MyWorkflow -PSComputerName server01, server02, server5001

I think your example of setting AD object attributes lends itself better to jobs or runspaces (PoshRSJob).

Workflow scripts are getting converted into C# code, compiled into .NET intermediate language (IL) and than executed. This compilation is very resource intensive and adds a significant delay to the overall experience. The delay is fine for long running processes but for quick tasks.

Something else you will discover is that each InlineScript block in your workflow will span a new PowerShell process which adds to the delay of things and increases resource usage. At some point in your attempt to create a workflow you will need to use InlineScript blocks because you need to use a cmdlets or functions of 3rd party PowerShell module which are not implemented as activities.


I was playing with this earlier. Definitely not intended for what you want to use it for.

enter a few usernames and check out how long this takes

workflow adusers {


foreach –parallel ($i in $users){

get-aduser $i}


adusers -users userone,usertwo

PS H:> Measure-Command {adusers -users a,b}

Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 349
Ticks : 3495247
TotalDays : 4.04542476851852E-06
TotalHours : 9.70901944444444E-05
TotalMinutes : 0.00582541166666667
TotalSeconds : 0.3495247
TotalMilliseconds : 349.5247

PS H:> Measure-Command {get-aduser a;get-aduser b}

Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 318

Hi Daniel.

Yeah I figured workflows are probably mostly useful for longer running processes where you want to follow a certain… workflow :slight_smile:

I saw a post on “The Scripting Guy” blog where use used foreach -parallel to create a bunch of users so I assumed it would faster then a non workflow, which unfortunately it wasn’t in my experience.
I’ll definitely go play around with workflows for stuff where it would seem more fitting.


Another thing to watch for is the serialization / deserialization that happens to data passed in and out of workflows.

There is a lot of convertion, and that will slow everything down a lot. So if it’s time sensitive workflows are not the way to go :slight_smile: