PowerShell interpreter
Last updated
Was this helpful?
Last updated
Was this helpful?
To use the PowerShell interpreter, you’ll first need to set up our, which contains the Azure integration.
PowerShell support is currently in beta, with general availability expected soon. We're gathering customer feedback to improve performance and expand context support. Scroll to the end of this page to view our current known issue list.
Rewst now supports PowerShell as a scripting option, giving you a familiar and flexible alternative to Jinja. PowerShell code can run in workflows, transitions, and data aliases by using secure Azure-hosted Function Apps deployed via Rewst. This means:
You write PowerShell in the same places you’d use Jinja, like the Live Editor or within a workflow.
You start a block with the #ps
header to tell Rewst to run that code using the PowerShell interpreter.
PowerShell is a command-line shell and scripting language used for automating tasks across Windows and other systems. Think of it as a way to write scripts that manage files, configure systems, and interact with services. It’s especially useful for MSPs who manage Microsoft-heavy organizations. If you’re new to Powershell, see .
When you use a #ps
block:
Your code is sent to a dedicated Azure Function App tied to your Rewst org.
The app runs the script in an isolated PowerShell environment.
The result is returned to Rewst and used just like Jinja output would be.
Only CTX and RESULT objects are available as context inside PowerShell blocks.
If you already know your way around PowerShell, there’s a good chance that you’ve used it to script against systems like Active Directory, Exchange, Intune, or local machine configurations. Rewst now lets you tap into those skills directly, without needing to learn Jinja first.
Microsoft’s free tier allows for 1 million function executions, plus 400,000 GB-seconds of compute each month. Beyond those free limits, additional executions are billed according to Azure’s pay-as-you-go rates. Typically, these are fractions of a cent per million executions, plus memory usage.
For many Rewst customers who only run occasional PowerShell workflows, the monthly cost is minimal or effectively $0 since this number of executions will fall within the free tier.
Higher-traffic organizations can pay Microsoft anywhere from a few dollars to tens of dollars a month for function usage, depending on volume and script complexity.
When creating an Azure Function App, the app name must be globally unique across all Azure tenants. This name is used not only for the Function App itself, but also for the associated App Service, storage account, and the app’s root URL.
To ensure uniqueness and avoid naming collisions, we use "rewstinterpreters" as the base name and append a UUID.
To start using PowerShell, you’ll need to deploy an Azure Function App interpreter through Rewst. We use a ZIP deployment process for the Function App code.
Make sure that you have successfully set up the Microsoft Cloud integration bundle before attempting these steps.
Navigate to Tools > Interpreters in the left side menu of your Rewst platform.
Click PowerShell (Beta) to expand the accordion menu. The two drop-down fields within the menu will populate with options pulled from your Azure instance, to line up with your subscriptions.
Click down carrot in the Subscription drop-down selector and choose your relevant subscription.
Click down carrot in the Resource Group drop-down selector and choose your relevant resource group.
Click Deploy.
This process may take a few moments. An in-progress message will display while you wait. You can leave the page if desired, without interrupting the deployment.
Once finished, a deployed message will appear at the bottom of the accordion menu, along with a Remove interpreter button. If deployment fails, a red error message will appear in a dialog on your screen.
Rewst creates the following in your Azure environment during deployment of the interpreter:
A PowerShell 7.4-based Function App
A shared consumption App Service Plan
Application insights for logging
A Storage Account for keys and triggers
If you don’t have Azure set up for your organization, you can override the Azure integration with a parent organization's configuration. This lets sub-orgs run PowerShell without duplicating infrastructure.
The Live Editor supports real-time PowerShell testing.
Navigate to Tools > Live Editor.
Click Jinja2 to switch the Live Editor over to PowerShell.
Use #ps
to start a PowerShell block:
Remember, don’t mix PowerShell and Jinja in the same block. You can use both in the same workflow, just not together in one snippet.
powershell CopyEdit #ps "Hello from PowerShell"
PowerShell works in:
Tasks – e.g., for generating dynamic output
Transitions – e.g., to determine conditional logic
Data Aliases – e.g., when transforming or mapping data
Use #ps
exactly as you would #jinja
:
#psl
headerThe interpreter also allows for a #psl
header for line-by-line PowerShell. Currently its use is limited and not the focus of our first version of the PowerShell interpreter. Use #ps
unless you're testing something specific.
Azure Function execution timeout for PowerShell is similar to that of Jinja. Expect 30-60 seconds for actions, and 10 seconds for parameters.
All output from PowerShell is processed as JSON. For best results, use ConvertTo-JSON
when returning data.
JSON Parsing Error: Blocks accessing `$CTX.user` due to an empty property name error during serialization.
Subworkflow Hangs: PowerShell code hangs silently in subworkflows when the parent uses Integration Override, breaking complex structures.
Azure Region Quotas: Users hitting deployment failures in popular regions (like East US) because subscription quotas are `0`. Requires manually selecting other regions.
Process Timeouts: PowerShell scripts time out near completion, causing failed workflow renders. Needs longer timeout limits.
Auth/Refresh Errors: Users get `401` errors (or Python `_'str' object has no attribute 'get'_` errors) when authorizing or refreshing resource groups, blocking setup.
Module Persistence: Modules installed during a run don't persist, forcing users to reinstall them in scripts every time.
UI Syntax Highlighting: Requires double backslashes (`\\`) in the UI editor while actual PS code needs single (`\`), causing confusion.
Serialization Failures: Returning non-JSON serializable objects (e.g., from `New-Item`) causes errors even if the command worked. Requires explicit `ConvertTo-Json`.
Common PS Pitfalls: Users misusing `Write-Host` (doesn't return output), not using `finally` blocks for output, or using incorrect `ConvertTo-Json` pipe syntax.
Live Editor Friction: Users can enter the Live Editor for PowerShell before the required Azure setup is complete, leading to confusion.
Have questions or feedback? Reach out to Support or post in your dedicated Discord support channel. Suggest improvements or new features in our feedback collector.