Build SSM Automation document configurations with multi-step workflows, branching logic, and approval gates.
Build SSM Automation document configurations with multi-step workflows, branching logic, and approval gates.
Required Fields
SchemaVersionMainStepsOutput will appear here...The builder validates that SchemaVersion and MainSteps resolve before accepting the JSON as a valid SSM Automation document, the minimum fields the CreateDocument API needs; it can't verify that step interpolations like {{describeInstance.InstanceState}} correctly reference an actually-declared prior step's output name, or that branch logic covers every realistic state, those errors only surface when the automation actually executes.
Build an SSM Automation document as a state-machine-style workflow of MainSteps, each an Action (aws:executeAwsApi, aws:branch, aws:changeInstanceState, aws:waitForAwsResourceProperty) that can reference prior steps' Outputs via {{stepName.OutputName}} interpolation, with aws:branch enabling conditional flow control based on a prior step's extracted value. A step lacking IsEnd: true and lacking any explicit NextStep implicitly falls through to the next step in array order, which is easy to get wrong when steps are reordered during editing, since Automation follows array position for implicit fallthrough, not step names, silently changing execution order in a way that isn't obvious from reading the JSON alone.
Reordering steps in the MainSteps array can silently change execution order for any step relying on implicit fallthrough (no NextStep, no IsEnd), always add explicit NextStep references (or IsEnd) rather than relying on array-position fallthrough, it makes the flow's actual logic visible in the JSON itself.
A destructive or high-impact step (stopping a production instance, deleting a resource) should be preceded by an aws:approve manual approval step referencing ApproverArn, don't rely solely on careful branch logic to prevent an automation from taking an unintended destructive action.
AssumeRole should be scoped tightly to exactly the API actions MainSteps actually calls, a broad pre-existing role reused for automation convenience means a bug in the automation's logic (an unintended branch path) has more blast radius than it should.
Execution implicitly falls through to whatever step comes next in the MainSteps array, by array position, not by any declared relationship. This is a common source of confusion when steps get reordered during editing, since nothing in a given step's own definition indicates which step follows it implicitly, always trace actual execution order by array position for any step lacking an explicit NextStep or IsEnd.
Via the {{stepName.OutputName}} interpolation syntax, referencing the earlier step's declared Name and the Name given to its Outputs entry. In the example, {{describeInstance.InstanceState}} references the InstanceState output declared on the describeInstance step, this interpolation only works for steps that already executed earlier in the flow, not steps later in the document.
No, if no Choices condition matches, execution proceeds to whatever Default step is specified (startInstance in the example), aws:branch always needs a Default to handle the non-matching case, an aws:branch without a Default and no matching Choice would leave execution with no defined next step, which is a configuration error, not a safe default of stopping.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.