Refresh articles

Author: cdpark

articles/logic-apps/add-run-powershell-scripts.md

@@ -1,11 +1,11 @@
 ---
-title: Add and run PowerShell in Standard workflows
+title: Add and Run PowerShell in Standard Workflows
 description: Write and run PowerShell script code in Standard workflows to perform custom integration tasks using Inline Code operations in Azure Logic Apps.
 ms.service: azure-logic-apps
 ms.suite: integration
 ms.reviewer: estfan, swghimire, shahparth, azla
 ms.topic: how-to
-ms.date: 08/13/2024
+ms.date: 05/23/2025
 # Customer intent: As a logic app workflow developer, I want to write and run PowerShell code so that I can perform custom integration tasks in Standard workflows for Azure Logic Apps.
 ---
 
@@ -23,11 +23,11 @@ This capability provides the following benefits:
 
 - Write your own scripts within the workflow designer so you can solve complex integration challenges. No other service plans are necessary.
 
-  This benefit streamlines workflow development plus reduces the complexity and cost with managing more services.
+  This benefit streamlines workflow development, and it reduces the complexity and cost with managing more services.
 
 - Generate a dedicated code file, which provides a personalized scripting space within your workflow.
 
-- Integrate with [Azure Functions PowerShell Functions](../azure-functions/functions-reference-powershell.md), which provides powerful functionality and inheritance for advanced task execution.
+- Integrate with [Azure Functions PowerShell functions](../azure-functions/functions-reference-powershell.md), which provides powerful functionality and inheritance for advanced task execution.
 
 - Deploy scripts alongside your workflows.
 
@@ -39,13 +39,13 @@ This guide shows how to add the action in your workflow and add the PowerShell c
 
 * The Standard logic app workflow where you want to add your PowerShell script. The workflow must already start with a trigger. For more information, see [Create example Standard logic app workflows](create-single-tenant-workflows-azure-portal.md).
 
-  You can use any trigger for your scenario, but as an example, this guide uses the **Request** trigger named **When a HTTP request is received** and also the **Response** action. The workflow runs when another application or workflow sends a request to the trigger's endpoint URL. The sample script returns the results from code execution as output that you can use in subsequent actions.
+  You can use any trigger for your scenario, but as an example, this guide uses the Request trigger named **When a HTTP request is received** and also the **Response** action. The workflow runs when another application or workflow sends a request to the trigger's endpoint URL. The sample script returns the results from code execution as output that you can use in subsequent actions.
 
 ## Considerations
 
-- The Azure portal saves your script as a PowerShell script file (.ps1) in the same folder as your **workflow.json** file, which stores the JSON definition for your workflow, and deploys the file to your logic app resource along with the workflow definition.
+- The Azure portal saves your script as a PowerShell script file (*.ps1*) in the same folder as your **workflow.json** file, which stores the JSON definition for your workflow, and deploys the file to your logic app resource along with the workflow definition.
 
-  The **.ps1** file format lets you write less "boilerplate" and focus just on writing PowerShell code. If you rename the action, the file is also renamed, but not vice versa. If you directly rename the file, the renamed version overwrites the previous version. If the action name and file names don't match, the action can't find the file and tries to create a new empty file.
+  The *.ps1* file format lets you write less "boilerplate" and focus just on writing PowerShell code. If you rename the action, the file is also renamed, but not vice versa. If you directly rename the file, the renamed version overwrites the previous version. If the action name and file names don't match, the action can't find the file and tries to create a new empty file.
 
 - The script is local to the workflow. To use the same script in other workflows, [view the script file in the **KuduPlus** console](#view-script-file), and then copy the script to reuse in other workflows.
 
@@ -60,7 +60,7 @@ This guide shows how to add the action in your workflow and add the PowerShell c
 
 1. In the [Azure portal](https://portal.azure.com), open your Standard logic app resource and workflow in the designer.
 
-1. In the designer, [follow these general steps to add the **Inline Code Operations** action named **Execute PowerShell Code** to your workflow](create-workflow-with-trigger-or-action.md?tabs=standard#add-action).
+1. In the designer, add the **Inline Code Operations** action named **Execute PowerShell Code** to your workflow. For detailed steps, see [Add an action to run a task](add-trigger-action-workflow.md?tabs=standard#add-action).
 
 1. After the action information pane opens, on the **Parameters** tab, in the **Code File** box, update the prepopulated sample code with your own code.
 
@@ -107,7 +107,7 @@ After you run your workflow, you can review the workflow output in Application I
 
 ## Access workflow trigger and action outputs in your script
 
-The output values from the trigger and preceding actions are returned using a custom object, which has multiple parameters. To access these outputs and make sure that you return the value that you want, use the [**Get-TriggerOutput**](#get-triggeroutput), [**Get-ActionOutput**](#get-actionoutput), and [**Push-WorkflowOutput**](#push-workflowoutput) cmdlets plus any appropriate parameters described in the following table, for example:
+The output values from the trigger and preceding actions are returned using a custom object, which has multiple parameters. To access these outputs and make sure that you return the value that you want, use the [Get-TriggerOutput](#get-triggeroutput), [Get-ActionOutput](#get-actionoutput), and [Push-WorkflowOutput](#push-workflowoutput) cmdlets plus any appropriate parameters described in the following table, for example:
 
 ```powershell
 $trigger = Get-TriggerOutput
@@ -121,34 +121,34 @@ Push-WorkflowOutput -Output $populatedString
 
 > [!NOTE]
 >
-> In PowerShell, if you reference an object that has **JValue** type inside a complex object, and you 
-> add that object to a string, you get a format exception. To avoid this error, use **ToString()**.
+> In PowerShell, if you reference an object that has *JValue* type inside a complex object, and you 
+> add that object to a string, you get a format exception. To avoid this error, use `ToString()`.
 
 ### Trigger and action response outputs
 
-The following table lists the outputs that are generated when you call **Get-ActionOutput** or **Get-TriggerOutput**. The return value is a complex object called **PowershellWorkflowOperationResult**, which contains thee following outputs.
+The following table lists the outputs that are generated when you call `Get-ActionOutput` or `Get-TriggerOutput`. The return value is a complex object called `PowershellWorkflowOperationResult`, which contains the following outputs.
 
 | Name | Type | Description |
 |------|------|-------------|
-| **Name** | String | The name for the trigger or action. |
-| **Inputs** | JToken | The input values passed into the trigger or action. |
-| **Outputs** | JToken | The outputs from the executed trigger or action. |
-| **StartTime** | DateTime | The start time for the trigger or action. |
-| **EndTime** | DateTime | The end time for the trigger or action. |
-| **ScheduledTime** | DateTime | The scheduled time to run the trigger or action or trigger. |
-| **OriginHistoryName** | String | The origin history name for triggers with the **Split-On** option enabled. |
-| **SourceHistoryName** | String | The source history name for a resubmitted trigger. |
-| **TrackingId** | String | The operation tracking ID. |
-| **Code** | String | The status code for the result. |
-| **Status** | String | The run status for the trigger or action, for example, **Succeeded** or **Failed**. |
-| **Error** | JToken | The HTTP error code. |
-| **TrackedProperties** | JToken | Any tracked properties that you set up. |
+| **Name** | String | The name for the trigger or action |
+| **Inputs** | JToken | The input values passed into the trigger or action |
+| **Outputs** | JToken | The outputs from the executed trigger or action |
+| **StartTime** | DateTime | The start time for the trigger or action |
+| **EndTime** | DateTime | The end time for the trigger or action |
+| **ScheduledTime** | DateTime | The scheduled time to run the trigger or action or trigger |
+| **OriginHistoryName** | String | The origin history name for triggers with the `SplitOn` option enabled |
+| **SourceHistoryName** | String | The source history name for a resubmitted trigger |
+| **TrackingId** | String | The operation tracking ID |
+| **Code** | String | The status code for the result |
+| **Status** | String | The run status for the trigger or action, for example, "Succeeded" or "Failed" |
+| **Error** | JToken | The HTTP error code |
+| **TrackedProperties** | JToken | Any tracked properties that you set up |
 
 <a name="return-data-to-workflow"></a>
 
 ## Return outputs to your workflow
 
-To return any outputs to your workflow, you must use the [**Push-WorkflowOutput** cmdlet](#push-workflowoutput).
+To return any outputs to your workflow, you must use the [Push-WorkflowOutput cmdlet](#push-workflowoutput).
 
 ## Custom PowerShell commands
 
@@ -170,7 +170,7 @@ None.
 
 ### Get-ActionOutput
 
-Gets the output from another action in the workflow and returns an object named **PowershellWorkflowOperationResult**.
+Gets the output from another action in the workflow and returns an object named `PowershellWorkflowOperationResult`.
 
 #### Syntax
 
@@ -190,8 +190,8 @@ Pushes output from the **Execute PowerShell Code** action to your workflow, whic
 
 > [!NOTE]
 >
-> The **Write-Debug**, **Write-Host**, and **Write-Output** cmdlets don't return values 
-> to your workflow. The **return** statement also doesn't return values to your workflow. 
+> The `Write-Debug`, `Write-Host`, and `Write-Output` cmdlets don't return values 
+> to your workflow. The `return` statement also doesn't return values to your workflow. 
 > However, you can use these cmdlets to write trace messages that appear in Application Insights. 
 > For more information, see [Microsoft.PowerShell.Utility](/powershell/module/microsoft.powershell.utility).
 
@@ -205,8 +205,8 @@ Push-WorkflowOutput [-Output <Object>] [-Clobber]
 
 | Parameter | Type | Description |
 |-----------|------|-------------|
-| **Output** | Varies. | The output that you want to return to the workflow. This output can have any type. |
-| **Clobber** | Varies. | An optional switch parameter that you can use to override the previously pushed output. |
+| **Output** | Varies | The output that you want to return to the workflow. This output can have any type. |
+| **Clobber** | Varies | An optional switch parameter that you can use to override the previously pushed output. |
 
 ## Authenticate and authorize access with a managed identity using PowerShell
 
@@ -216,7 +216,7 @@ From inside the **Execute PowerShell Code** action, you can authenticate and aut
 
 To use the managed identity from inside the **Execute PowerShell Code** action, you must follow these steps:
 
-1. [Follow these steps to set up the managed identity on your logic app and grant the managed identity access on the target Azure resource](authenticate-with-managed-identity.md?tabs=standard).
+1. Set up the managed identity on your logic app and grant the managed identity access on the target Azure resource. To learn how, see [Authenticate access and connections to Azure resources with managed identities](authenticate-with-managed-identity.md?tabs=standard).
 
    On the target Azure resource, review the following considerations:
 
@@ -248,15 +248,15 @@ To use the managed identity from inside the **Execute PowerShell Code** action,
 
 1. Go to your logic app's root location: **site/wwwroot**
 
-1. Go to your workflow's folder, which contains the .ps1 file, along this path: **site/wwwroot/{workflow-name}**
+1. Go to your workflow's folder, which contains the *.ps1* file, along this path: **site/wwwroot/{workflow-name}**
 
 1. Next to the file name, select **Edit** to open and view the file.
 
 <a name="log-output-application-insights"></a>
 
 ## View logs in Application Insights
 
-1. In the [Azure portal](https://portal.azure.com), on the logic app resource menu, under **Settings**, select **Application Insights**, and then select your logic app.
+1. In the [Azure portal](https://portal.azure.com), under **Monitoring** on the logic app resource menu, select **Application Insights**, and then select your logic app.
 
 1. On the **Application Insights** menu, under **Monitoring**, select **Logs**.
 
@@ -299,7 +299,7 @@ To find publicly available modules, visit the [PowerShell gallery](https://www.p
    }
    ```
 
-1. Open the file named **requirements.psd1**. Include the name and version for the module that you want by using the following syntax: **MajorNumber.\*** or the exact module version, for example:
+1. Open the file named **requirements.psd1**. Include the name and version for the module that you want by using the following syntax: `MajorNumber.*` or the exact module version, for example:
 
    ```powershell
    @{
@@ -332,7 +332,7 @@ You can generate your own private PowerShell modules. To create your first Power
 
 1. In the **Modules** folder, create a subfolder with the same name as your private module.
 
-1. In your private module folder, add your private PowerShell module file with the **psm1** file name extension. You can also include an optional PowerShell manifest file with the **psd1** file name extension.
+1. In your private module folder, add your private PowerShell module file with the *psm1* file name extension. You can also include an optional PowerShell manifest file with the *psd1* file name extension.
 
 When you're done, your complete logic app file structure appears similar to the following example:
 
@@ -359,13 +359,13 @@ In this release, the web-based editor includes limited IntelliSense support, whi
 
 ### A workflow action doesn't return any output.
 
-Make sure that you use the **Push-WorkflowOutput** cmdlet.
+Make sure that you use the `Push-WorkflowOutput` cmdlet.
 
 ### Execute PowerShell Code action fails: "The term '{some-text}' is not recognized..."
 
 If you incorrectly reference a public module in the **requirements.psd1** file or when your private module doesn't exist in the following path: **C:\home\site\wwwroot\Modules\{module-name}**, you get the following error:
 
-**The term '{some-text}' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name or if a path was included, verify the path is correct and try again.**
+    **"The term '{some-text}' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name or if a path was included, verify the path is correct and try again."**
 
 > [!NOTE]
 >
@@ -374,7 +374,7 @@ If you incorrectly reference a public module in the **requirements.psd1** file o
 
 ### Execute PowerShell Code action fails: "Cannot bind argument to parameter 'Output' because it is null."
 
-This error happens when you try to push a null object to the workflow. Confirm whether the object that you're sending with **Push-WorkflowOutput** isn't null.
+This error happens when you try to push a null object to the workflow. Confirm whether the object that you're sending with `Push-WorkflowOutput` isn't null.
 
 ## Related content