Python, Meet the Canvas: What’s New in Itential Platform 6.4

Itential Platform 6.4 adds a “Run Code” task that lets workflow builders write and execute Python directly on the Workflow Canvas using IAG 5’s isolated runtime. The update matters to enterprise IT and security teams because it changes how workflow logic, compliance visibility, and integration execution fit into existing environments.

Research Overview

The vendor describes Platform 6.4 and IAG 5.4 as updates focused on workflow authoring on the Canvas, operational visibility for production execution, and deployment fit within enterprise security architectures. The post frames these changes around requirements raised by enterprise customers and operators.

Alongside the Canvas change, the release includes additions tied to Configuration Manager compliance reporting, proxy configuration for integrations, and visibility features for job execution and task focus on the Canvas.

Key Findings

The central capability is the Run Code task, which the post says allows Python execution to occur inside a workflow task on the Workflow Canvas instead of requiring a separate IAG Python service. Itential states this supports data manipulation, conditional logic, and computational operations, with Python code stored in the task and testable at design time with live inputs and outputs.

The post also reports new operational and management features: job execution path visibility using color outcomes on the Canvas, consistent service configuration description fields across adapters and integrations, and task focus indicators that center and highlight a selected task in large workflows.

Technical Breakdown

For the Workflow Canvas, Itential describes the Run Code task as executing Python through IAG 5’s isolated runtime, with code stored within the task. The post states that workflow builders can embed logic for inline cases directly in the canvas and keep orchestration readable, while shared or heavier logic continues to use IAG Python services.

For customer environments with controlled outbound paths, Platform 6.4 introduces centralized proxy configuration, with HTTPS proxy settings set at the feature level and inherited by integrations by default. The post says integration execution routes through IAG 5 rather than directly from the platform layer so outbound API calls follow customer proxy controls, and it adds that cloud-managed customers targeting on-premises systems can avoid VPN tunnels previously required to bridge environments.

Operational Impact

For Configuration Manager customers running compliance checks at scale, the post says a reporting dashboard adds plan-level compliance scores, connection success rates, device coverage, and trend data across configurable time windows. It also describes drill-down paths from fleet-wide overviews to individual plan runs, device-by-device results, and specific connection errors, plus a redesigned plan creation wizard.

On gateway and IAG operations, IAG 5.4 is described as adding “iagctl inspect cluster” commands for viewing in-flight and recently completed work and running reachability and readiness health checks, including a combined command. The release also includes automated pruning of idle Python virtual environments, Python service boolean switch support via argparse store_true, named profiles in iagctl config, and extended OpenTofu support for remote backends and partial config options.

Blog Signals brief is a fact-based summary of the vendor blog describing Itential Platform 6.4 and IAG 5.4 changes, including Run Code Python on the Workflow Canvas, compliance reporting enhancements, proxy configuration support for integrations, and operational visibility and maintenance tools for IAG gateway clusters.