Orchestration - using PowerShellProbe API within "Run Script" nodes in workflow results in stuck workflowIssue With Orchestration it is possible to leverage the MID Server to complete PowerShell actions inside a Workflow. Using the "execute" method on the "PowerShellProbe" API directly inside a "Run Script" node in the workflow may result in a stuck workflow.SymptomsWorkflow using "execute" method on "PowerShellProbe" API within a "Run Script" node is stuck. Workflow Context logs show transaction cancelled due to max runtime. ReleaseAllCauseCalling "execute" method on "PowerShellProbe" API directly inside a "Run Script" node will submit an ecc_queue record with the desired details for the MID Server to pick up and execute asynchronously. The transaction running this node of the workflow will then wait for the retrieved response. The transaction will be cancelled if the total runtime is longer than the max transaction time - which means that if the script takes a long time to process or if the MID Server is busy the transaction is likely to be cancelled. As the transaction is cancelled, the workflow will not continue. ResolutionAs this issue only occurs when using the "execute" method on the "PowerShellProbe" API directly within a "Run Script" node in the workflow, it is best to avoid calling the "PowerShellProbe" directly. This is not a supported method of running PowerShell during Workflows, and even if the probe completes faster than the transaction timeout it will hold system scheduled worker threads open while awaiting the asynchronous response which is inefficient. The best method to avoid this is by utilising Flow Designer, along with the IntegrationHub and appropriate spokes to achieve the desired functionality. Custom PowerShell scripts may be used in PowerShell steps within Flow Designer. The IntegrationHub has many spokes available through the ServiceNow Store and it is likely that a spoke may already exist that provides the functionality required by the Flow. If intending to leverage the legacy Orchestration product to achieve this, then the correct approach in such scenarios is to use a PowerShell activity. Custom PowerShell activities may be designed through the Activity Designer. PowerShell activities handle the asynchronous communication correctly, allowing the workflow to wait for MID Server response without causing transaction timeout. The documentation for creating a custom PowerShell activity can be found at this link: https://www.servicenow.com/docs/csh?topicname=c_PowershellActivityDesigner.html&version=latest