Bridging the Gap: Native PowerShell Scripting in Automation Anywhere A360

Problem Statement

Automation Anywhere A360 provides strong built-in scripting support through its JavaScript package, but many enterprise IT and automation teams work primarily in PowerShell. PowerShell is the dominant scripting language for Windows system administration — Active Directory management, registry queries, service control, file operations, and REST API calls are all tasks that IT teams manage in PowerShell daily.

Without native PowerShell support, A360 developers face an uncomfortable choice: rewrite existing PowerShell logic in JavaScript or VBScript or resort to running PowerShell indirectly through command-line workarounds that offer no structured output capture, no error handling, and no timeout control. Either path introduces unnecessary complexity, increased maintenance burden, and creates a barrier for IT professionals who want to contribute to automation development but are not JavaScript developers.

Solution Overview

The PowerShell Integration package adds native PowerShell scripting to A360 following the familiar Open / Run / Close pattern already used by the built-in JavaScript package. Developers open a named PowerShell session, execute scripts either inline in the editor or from an external .ps1 file, capture the output directly into a native A360 variable, and close the session — all without having to install additional runtimes or tools on the agent machine.

The package is built using the Automation Anywhere Package SDK and runs on the standard Windows PowerShell installation already present on every Windows bot agent machine. It supports both Windows PowerShell 5.1 and the newer cross-platform PowerShell 7+ if present.

Implementation Considerations:

Session Architecture

The package follows A360’s established session pattern, storing the PowerShell executable path and execution policy in a session object created at Open time. This keeps configuration centralized and consistent across multiple Run actions within the same process while remaining lightweight — there is no persistent PowerShell process between script executions.

Script Execution

Each Run action writes inline scripts to a temporary UTF-8 encoded .ps1 file and invokes it via ProcessBuilder, passing -NonInteractive -NoProfile -ExecutionPolicy flags to ensure consistent, profile-independent execution in the bot agent context. The temporary file is always cleaned up after execution regardless of outcome.

Output and Error Handling

Stdout and stderr are captured on separate threads — a critical design decision, as reading a single merged stream can deadlock the process if either buffer fills while the other is being read. On completion, stdout is returned as the action output.

Stderr handling is controlled by an ErrorAction setting:

• Stop mode (recommended) treats any stderr output as a failure even when the exit code is zero, catching non-terminating PowerShell errors that would otherwise be silently swallowed.
• Continue mode logs stderr to the agent log and proceeds.

Timeout Control

A configurable timeout field on the Run action uses Java’s process.waitFor(timeout, TimeUnit.SECONDS). If the timeout is exceeded the process is forcibly terminated and a structured exception is thrown containing the exit code, any stderr output, and any partial stdout captured before termination — giving the developer full visibility into what the script was doing when it timed out.

Execution Policy

Rather than hardcoding Bypass, the Open action exposes an execution policy radio selector (Bypass, RemoteSigned, AllSigned, Unrestricted). This accommodates organizations with stricter security requirements while keeping Bypass as the sensible default for most bot agent contexts.

Agent Compatibility 

The Open action probes the selected executable at session creation time, failing fast with a clear error if PowerShell cannot be located. It also detects JVM vs PowerShell bitness mismatches — a subtle issue on 64-bit Windows where a 32-bit JVM can be silently redirected to the 32-bit PowerShell by the Windows File System Redirector, causing unexpected behavior with scripts that depend on 64-bit registry hives or System32 paths.

Key benefits:

Eliminating Rewrites

• Bot developers can call existing PowerShell scripts directly from A360 without rewriting them in another language, reducing development time and eliminating a parallel maintenance burden
• IT teams who own PowerShell scripts retain ownership of them — the bot simply calls the script rather than duplicating its logic

Clean, Structured Error Visibility

• Stdout and stderr are always separated; bot developers see exactly what the script produced versus what went wrong
• The ErrorAction setting prevents the common pitfall of non-terminating PowerShell errors being silently ignored, a source of difficult-to-diagnose bugs in command-line based workarounds
• Timeout exceptions include partial output captured before termination, giving developers meaningful diagnostic information rather than a bare timeout message

Familiar Developer Experience

• The Open / Run / Close pattern is identical to the built-in JavaScript package, meaning any A360 developer already familiar with that package can use PowerShell Integration immediately
• Bot variables are passed to scripts using PowerShell’s native -Parameter "value" syntax in the Arguments field, keeping the integration intuitive for PowerShell developers
• The package is free, requires no third-party accounts or licenses, and has no dependencies beyond the Windows PowerShell installation already present on the agent machine