System Actions

The System Actions enable ThinkAutomation to interact directly with the underlying operating system and external applications. These actions allow your Automations to run PowerShell scripts, execute programs, and temporarily switch user context for access to network resources or desktop-level operations. System Actions are commonly used for server administration, data processing tasks, application integration, workstation automation, and workflows that require elevated or user-specific permissions. By leveraging these actions, you can extend Automations beyond messaging and data processing into full system orchestration.

Execute PowerShell

Executes a Windows PowerShell command or script. Returns the response to a ThinkAutomation variable.

Enter the PowerShell Command or Script or specify PowerShell Script File.

In the PowerShell Command or Script you can either specify the command and it's parameters or you can specify the command only and then provide parameter names, values & types in the Parameters Grid.

Example - Single Command With Parameters

To get the current Windows version. Set the PowerShell Command to Get-ItemProperty and add parameters:

Parameter Name	Value	Type
Path	HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion	String
Name	ReleaseId	String

You can use %variable% replacements for parameter values (or part of).

If you need to pass multiple values to a single parameter, you need to send through a special ThinkAutomation array type. To do this, prefix your parameter value with the word ARRAY: followed by comma-separated values.

This will return:

ReleaseId    : 2009
PSPath       : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
PSParentPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT
PSChildName  : CurrentVersion
PSDrive      : HKLM
PSProvider   : Microsoft.PowerShell.Core\Registry

Example - Command

You can also execute a PowerShell command/script. Set the Command to:

(Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" -Name ReleaseId).ReleaseId

You can use %variable% replacements inside the Command, eg:

(Get-ItemProperty -Path "%RegKey%" -Name ReleaseId).ReleaseId

Nothing should be specified in the Parameters grid.

The above will return 2009.

Remember to enclose string parameters in quotes.

Wait Max (Seconds)

Specify the maximum seconds to wait for the command or script to execute. If the command or script does not complete within the specified number of seconds then an error will be raised. This setting prevents scripts that do not properly handle timeouts from halting execution of the Automation.

Assign To

Select the variable that you want the Response to be assigned to. The entire PowerShell command response will be assigned to the field/variable.

Testing

You can use the Test button to test the Command/Script. The response will be displayed and also copied to the clipboard.

External Modules

If your PowerShell command or script uses external modules/cmdlets you need to enter the module names in the Import Module Names entry. Separate multiple modules with commas. You can use the module name or path.

In order to be able to run the PowerShell script you need to set an appropriate PowerShell Execution Policy. For guidance on this from Microsoft, see: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-6

Run A Program

Execute any Windows program or command with optional parameters. The Output of the program can be assigned to a variable.

Enter the Program Or Command To Run and any Parameters. You can use %fieldname% replacements in both entries.

Run Via

This option defines which process runs the program:

Run Via: Message Processor Service

The Message Processor service itself runs the program. You can optionally specify user Credentials that the program should execute as.

Run Via: ThinkAutomation Studio Or Desktop Connector On Behalf Of The Message Processor Service

The message processor service sends a request to the ThinkAutomation Studio or Desktop Connector to start the program on it's behalf. The Studio/Desktop Connector executes the program and sends the results back to the message processor.

You also have the option to specify a ThinkAutomation User Name if you want the program to be executed by a specific logged in Studio/Desktop connector user (for example a user running the Studio on a remote machine). If no user is specified then the process will be executed by the first running instance of the Studio/Desktop connector.

This option can be used in instances where the program you want to run needs to execute under the security context of the logged in Windows user rather than under the security context of a running service. For example, you may have an AutoIt script that interacts with the user's desktop applications. However for this to work the ThinkAutomation Studio or Desktop Connector applications must be running when the Automation executes.

Redirect Output

Select the Redirect Output if you want to receive the output of the program. The output can then be assigned to a variable selected from the Assign Output To list.

Wait For Exit

Select the Wait For Exit option if you want ThinkAutomation to wait for the program to complete before continuing with the remaining actions on the Automation. You can also specify a Wait Max in milliseconds.

The Login As User action can be used to temporarily change the user context that the currently processing message is executing under.

By default the ThinkAutomation Message Processor service runs under the local SYSTEM account. The SYSTEM account will not have access to any network resources (Printers, Network Drives, Remote paths etc). Therefore, if you need your Automation to access network drives, or access any network resource you must use the Login As User action within your Automation, or run the ThinkAutomation Message Processor service under a different user. See: Changing The User Context.

Specify the Domain, User Name and Password (these can be variables). Enable the Use Network Credentials option if the user is a network user.

Note: The password is stored encrypted.

You should place this action before any actions that require the user credentials.

When the Automation executes, the current user context will be changed when this action is executed. If the login fails, an error will be raised.

At the end of the Automation, the user context will revert back to the default (unless another Login As User action is used).