I'm having a strange issue with my Azure Automation PowerShell runbook that gets triggered through a Power Automate flow. The runbook has the following parameters: UPN, fullName, and ToNumber, all defined as strings. However, when I pass a specific mobile phone number (starting with 04), it's being recognized as an octal number and converting it to decimal (68xxxxxx). I thought defining it as a string would prevent this, so I'm puzzled about what's happening. Interestingly, this problem doesn't occur when I run the runbook manually; the input shows the correct number in quotes during manual runs. It seems like there's some input handling happening when triggered by Power Automate that's not happening elsewhere. Has anyone else encountered this?
3 Answers
This is really odd! It sounds like you might be facing a parsing issue specific to how Power Automate sends data to Azure Automation. If you can replicate it consistently, reaching out for support might be the way to go. Although I've had mixed luck with them in the past, they might be able to provide insight or escalate to a bug report.
Quick side note—why use Power Automate to trigger your runbook? If it's all feasible within Power Automate, you might streamline the process by just using connectors instead. Could save a lot of hassle!
Good point! The runbook uses SMS services through their API, and I thought PowerShell was the best way. Turns out there's now a Power Automate connector for that SMS provider, which I just found out while troubleshooting!
I remember running into a similar issue a while back. Using double quotes in Power Automate when passing parameters helped avoid data type misinterpretations. Have you given that a try?
I've faced similar frustrations! Another option could be explicitly converting your input to a string in Power Automate before sending it off to Azure Automation. That might help avoid the octal conversion.