One of the most common feedback I’ve heard from community peers and customers about PowerShell is that it can’t handle reboots… You would have to do some creative scripting which can only handle a simple reboot but not a situation where the device has been shutdown for an entire day or longer. This is something a lot of automation tools can, so I think it’s understandable that people would want Powershell to be able to do this.

With the introduction of Powershell Workflow in Windows 8, PowerShell provides an answer to that request.

What is workflow?
A workflow is a sequence of automated tasks, mostly of the times (so not always!) across multiple devices. The strength of a workflow is that it will resume after a reboot, network outage or even a power loss.

How can I invoke a Powershell workflow?
Simply by typing the name of the workflow just as you would with any other Powershell command:

Invoke-MyWorkflow

And just to make it more interesting, you can also run workflows on the background as a job… the same way as you would run any other Powershell command as a job, by using the –AsJob parameter

Invoke-MyWorkflow –AsJob

Powershell Workflow makes use of the already existing job infrastructure within PowerShell, so all the same rules apply such as Wait-Job, Receive-Job, Stop-Job, etc.
But with Powershell v3 you can also use Suspend-Job and Resume-Job

How can I run a Powershell workflow?
Rather simple actually… put the “workflow” keyword in front of the name of your workflow and let it be followed by the body of the workflow Let’s take an example:

workflow Invoke-MyWorkflow {“Blah, blah… Woof, woof!”}

Parallel or sequential execution of Workflow Activities
By using the “parallel” keyword you can run the tasks within the workflow parallel from each other. But when you want some tasks within a parallel workflow to be executed in a sequence, you can do that by using the “sequence” such as within the following example:

workflow Invoke-ParallelWorkflow {
  parallel {
    Get-Process -Name PowerShell
    sequence {
      "In sequence 1 of 2"
      "In sequence 2 of 2"
    }
    "In parallel 1 of 2"
    "In parallel 2 of 2"
    Get-Service -Name WinRM
  }
}

Which parameters can I use with a workflow?
Well… a lot actually!

Name	Description
AsJob	Runs the workflow as a background job on the local device.
InputObject	Specifies a variable or expression as input to the workflow.
JobName	Specifies a friendly name for je job since the default is “Job<ordinal number>”.
PSAllowRedirection	By default, Windows PowerShell Workflow does not redirect connections, but this parameter allows you to do just that.
PSApplicationName	By default, Windows PowerShell Workflow uses WSMAN, where this parameter allows you to choose a different parameter.
PSAuthentication	Specifies the mechanism to use for credential validation. Possible values are: Default, Basic, Credssp, Digest, Kerberos, Negotiate, and NegotiateWithImplicitCredential.
PSAuthenticationLevel	Specifies the authentication level to use for WMI connections. Possible values are: Unchanged, Default, None, Connect, Call, Packet, PacketIntegrity, PacketPrivacy.
PSCertificateThumbprint	Specifies the digital public key certificate (X509) of a user account that has permission to perform this action by certificate thumbprint.
PSComputerName	Specifies a list of target devices where the workflow will be executed on.
PSConfigurationName	Specifies the session configuration, default is Microsoft.PowerShell, that is used for the connection to the target device.
PSConnectionRetryCount	Specifies the number of times a workflow should retry connecting to the target devices before failing.
PSConnectionRetryIntervalSec	Specifies the number of seconds to wait between each successive connection retry.
PSConnectionURI	Specifies a (fully qualified) Uniform Resource Identifier (URI) where the default is http://localhost:5985/WSMAN. Format example: <Transport>://<ComputerName>:<Port>/<ApplicationName>
PSCredential	Specifies the credentials to use for the workflow execution on the target devices.
PSElapsedTimeoutSec	Specifies the maximum number of seconds the workflow is allowed to run. If the threshold is exceeded, the workflow will be terminated. This includes the time in which the job is in a suspended state!
PSParameterCollection	Specifies a list of hash tables to specify different parameter values for different target devices.
PSPersist	Forces the workflow execution to checkpoint the workflow data and state after each executing each step (activity) within the workflow.
PSPort	Specifies the port to be used for the WinRM connection to the target devices where the defaults are port 5989 for HTTP and 5986 for HTTPS.
PSPrivateMetadata	Specifies the hash table object that represent the user or application level information that can later be used to identify/filter the workflow execution.
PSRunningTimeoutSec	Specifies the maximum number of seconds the workflow is allowed to run. If the threshold is exceeded, the workflow will be terminated. This DOES NOT include the time in which the job is in a suspended state!
PSSessionOption	Specifies the advanced options for the connection to target device.
PSUseSSL	Specifies to use SSL to connect to the target device, hence PowerShell Workflow doesn’t use SSL by default.

More information?
Download the WMF3 CTP2 Windows PowerShell Workflow.pdf from here.