Introduction

Most of these tips apply to both services. If the tip doesn’t apply to both, the tip will explicitly call out SMA or Azure Automation. When you see the term Automation used, the tip refers to both. These tips do not go into detail about
why we suggest you follow this guidance. For more detail on PowerShell Workflow and runbook, look at our
runbook authoring documentation and PowerShell Workflow introduction guide.

Also check out this
PowerShell Workflow Gotchas wiki that highlights some of the most frequently problems that SMA and Azure Automation users run into.

General Guidance

follow the naming convention for PowerShell cmdlets when you name your runbooks / PowerShell workflows: <ApprovedVerb>-<Noun>.

test your workflow in Automation, especially if you authored it in a local environment first.

explicitly define which parameters are and are not mandatory.

CONSIDER

using an InlineScript block if you're going to use the pipeline.

AVOID

strongly typing runbook parameters which are not primitive types.

interacting with or depending upon local server resources on the Runbook Worker if you are using
SMA.

relying on any resources you yourself have not copied to the runbook host in
Azure Automation. If you need to use a file, checkpoint then copy it to the host to ensure it will be where you expect it.

using the pipeline (i.e. chaining cmdlets with the “|” character) in PowerShell Workflow, unless you understand that a complex object is not being passed through the pipeline.

creating runbooks that are expected to execute for an excessively long time period. If you want a monitor runbook to run all the time, start a new instance of it by calling Start-SMARunbook or Start-AzureAutomationRunbook before the job completes.