PowerShell Runbooks convert string-inputs with leading zeros as octal and convert them to deca

Question

Hi all.

There's a weird behavior in Azure Runbooks, where string inputs get converted as octa to deca-numbers although their are defined as string-parameters.

When calling the runbook from the Azure-UI it all works as expected.
But when calling it from Power Automate the described behaviour occurs.

Reproduce:

Create a Azure Runbook, define one string input.
Simply put one line of code to print the input.

param(
    [Parameter(Mandatory = $true)][string]$MyInput
)

Write-Output "[Input] MyInput: $MyInput" 

Make the input "00066".

The expected output is "00066".

The actual output is "54", a conversion from 66 (octa) to deca.

I currently work around this issue by sending a "X"-character in front of the number and remove it inside the script.
With the input "X00066" and this script it works as expected.

param(
    [Parameter(Mandatory = $true)][string]$MyInput
)

Write-Output "[Input] MyInput: $MyInput" 
$result = $MyInput -replace "X", ""
Write-Output "Substitute X for nothing: $result"

Does anyone know how to prevent this behavior?

Kind regards.

Answer 1

Hello Frank Muraschow,

Thank you for reaching out to the Microsoft Q&A forum.

This odd conversion is actually coming from PowerShell’s literal‐to‐number rules rather than Azure Automation itself. If you pass “00066” as a true string (e.g. in the Azure portal) it stays “00066,” but when Power Automate kicks off your runbook it’s serializing the parameter as a JSON number—PowerShell then sees a leading zero and treats it as an octal literal (066₈ → 54₁₀).

Here’s what you can do:

Force Power Automate to send it as a JSON string

If you’re using the HTTP/Webhook action, make sure your body is something like { "MyInput": "00066" } (i.e. include the quotes around 00066).

If you’re using the Azure Automation connector, wrap the value in a Compose or Convert to string action so the parameter is sent as text, not number.

Explicitly convert inside your runbook If for some reason you can’t change the PA side, you can defensively re-cast in PowerShell:

param(
  [Parameter(Mandatory=$true)][string]$MyInput
)
# This wipes out any implicit numeric conversion

$MyInput = [string]$MyInput
Write-Output "[Input] MyInput: $MyInput"

Keep your “X” workaround Prefixing with a non-numeric character (like “X00066”) will always force string parsing, then strip it off as you’ve been doing.

Hope that clears it up!

Reference links

• PowerShell string→number conversion rules (leading zero = octal): https://learn.microsoft.com/powershell/scripting/lang-spec/chapter-06?view=powershell-7.5#616-conversion-from-string-to-numeric-type

• How JSON numbers get parsed in PowerShell/webhooks: send values as JSON strings to preserve leading zeros

 

Answer 2

PowerShell automatically converts strings that look like numbers into numeric types in many situations. In Azure Automation runbooks, not all PowerShell parameter attributes and behaviors are supported, and input coming from external callers (like Power Automate) can be coerced differently than when starting the runbook from the Azure portal.

Key points from the documented behavior:

• Azure Automation supports only a limited set of parameter attributes for runbooks: Type, Name, Mandatory, and Default value. Other PowerShell parameter features (such as more advanced validation and some binding behaviors) are not supported.
• Not all PowerShell input parameter behaviors are supported in Azure Automation, and there is a known issue that runbooks can fail or behave unexpectedly based on input values.
• PowerShell’s language rules allow conversion from string to numeric types; an empty string becomes zero, and numeric-looking strings are interpreted as numbers according to PowerShell’s conversion rules.

In this scenario, the value "00066" is being interpreted as a numeric literal and converted before it reaches the runbook as a pure string, which results in the octal-to-decimal conversion behavior being observed when invoked from Power Automate.

To prevent this behavior, ensure that the value is treated as a non-numeric string by the caller so that Azure Automation does not attempt numeric coercion. Practical options include:

1. Prefixing the value with a non-numeric character (as already done with "X00066") and stripping it inside the runbook.
2. Ensuring the caller sends the value in a way that is clearly a string and not a number (for example, by quoting or otherwise formatting it so that it cannot be parsed as a numeric literal by the calling system before it reaches the runbook).

Because Azure Automation does not support the full range of PowerShell parameter behaviors and has known limitations around input parameters, working around the automatic numeric conversion at the caller side is the reliable mitigation.

---

References:

• Configure runbook input parameters in Automation
• Azure Automation runbook types
• 6. Conversions