Working with PowerShell Script Step Output
  • 25 Mar 2025
  • 4 Minutes to read
  • Dark
    Light

Working with PowerShell Script Step Output

  • Dark
    Light

Article summary

Overview

When using a PowerShell Script step in a Flow within Decisions, the way the script is executed plays a crucial role in determining how the output is handled and what path the Flow will follow afterward. This step provides automation capabilities by running PowerShell code within the Flow. This documentation explains how various types of outputs, including structured objects with properties and simple text strings, are managed. It also covers how the execution outcome affects the Flow's progression, whether it concludes as Done, Done With Errors, or Failed. Additionally, this guide explores how to handle non-terminating errors and configure remote execution for PowerShell steps.


Scripts that Output PowerShell Objects

Some PowerShell Scripts return lists of PowerShell objects from which Decisions can select the user's desired properties. The script below is an example of this. The sample script can be imported into Decisions.

   Powershell-Sample-Scripts.zip  

The step retrieves a list of processes running on the Decisions server, and the script definition tells Decisions to select the ID and Process Name properties from the objects that the script returns. Each of these properties appears in the Outputs area of the step as an array of values. The PowerShell Module Basics provides details on this sample script.


Scripts that Output Text

Other PowerShell scripts can return results as text. A simple example of this is the following PowerShell Script:

$Variable = "This is an example of string output."
Return $Variable

Because this PowerShell script does not return an object with properties, there are no properties for Decisions to select, and therefore no need to specify anything in the Outputs area of the script.

When this PowerShell Script is added as a Flow step, users can access the script's output in the Edit Input Mappings using the Script Raw Output, a single text string containing all of the lines of output that the script generated.


Non-terminating Errors

Some commands in PowerShell scripts do not halt script execution when they encounter a problem. They write error messages to a special error stream instead. This output can be mapped from a PowerShell Script step using the Non-terminating Errors output of the step.

This is a separate output stream from the Script's Raw Output and contains all the errors that any portion of the script wrote. An example script that writes to this output stream is:

$Error_Message = "This is a non-terminating error"
Write-Error $Error_Message
Return
The script above does not return any objects or any Raw Script Output. If a Flow step is created using it, its Non-terminating Errors property will contain the error message text when the Flow is run. Because more than one error message can be written, Decisions provides the Non-terminating Errors as an array of strings.

PowerShell Script Step Paths

Because PowerShell scripts can run to completion but still generate error messages, Decisions provides multiple paths out of a PowerShell Script Step:

PathTaken When
DonePowerShell script ran successfully.
Done With ErrorsPowerShell script completed, and errors were written to the Non-terminating Errors property.
FailedPowerShell script encountered an error that halted its execution. Instead of any normal output or non-terminating errors, an Exception Details property is provided.

Note:
Both the Done With Errors and Failed paths can be hidden using the Hide Done With Errors Path and Hide Failed Path checkboxes under the properties panel on the right.

Running PowerShell Steps Remotely

PowerShell Script Steps can be Run Remotely by enabling the option "Run Remotely" from the properties panel.

Note:
  • Ensure that you have the necessary permissions to run the steps remotely and that the remote machine has winrm enabled and set to listen to your IP. Refer to the article "Run PowerShell Remotely."
  • When running PowerShell steps remotely, you can manage how credentials are handled during debugging:
    • With Constant Credentials: If you check "Use Constant Credentials", the username and password will not be visible in plain text when debugging. However, you must add these credentials for each new step dropped into a Flow. This approach is more secure as it removes the credentials from step inputs and moves them to settings.
    • Without Constant Credentials: If you uncheck "Use Constant Credentials", the username and password will be visible in plain text when debugging for debugging purposes. This is less secure.

Refer to and enter all the input details as per the following table:

Domain\User NameEnter the IP_Address\username of the remote system.
PasswordPassword of the User.
Port NumberThe port PowerShell runs on, by default, is set to 5985.
Remote Computer NameIP Address of the remote system.
Use SSLIf enabled, it will use a secure connection and thus need to change the Port Number to 5986.

Enabling the Run Remotely option will expose another setting, Use Constant Credentials. Enter all the input details as per the following table to make use of constant credentials to connect to the PowerShell:

User NameEnter the IP_Address\username of the remote system
PasswordPassword of the User
Port NumberThe port PowerShell runs on, by default, it is set to 5985
Remote Computer NameIP Address of the remote system
Use SSLIf enabled, it will use a secure connection and thus need to change the Port Number to 5986

For further information on Modules, visit the Decisions Forum.

Was this article helpful?

What's Next