Designer
In Azure Logic Apps Automation, the designer provides a visual drag-and-drop canvas where developers can shape workflows. Every workflow component, such as the trigger, each action, agent, and MCP server, has a parameters pane for inputs and settings, code view, and outputs view so you can easily move between the visual representation and the underlying JSON.

What you can build on the designer
Section titled “What you can build on the designer”The following table describes only some of the components that you can use on the designer to build your workflow:
| Component | Description |
|---|---|
| Trigger | Starts the workflow from an HTTP call, a schedule recurrence, a queue message, an event, or another workflow. |
| Action | Run one or more steps that perform tasks on other services, systems, apps, and data, execute inline JavaScript, or call other workflows. |
| Control flow | Structure your workflow with if-else, switch, for-each, do-until, and parallel branch constructs. |
| Nested logic | Group actions into scopes. Nest control flow constructs as deeply as you need. |
| Variables and expressions | Capture intermediate values and reference them by using expressions. |
Conditional branches
Section titled “Conditional branches”The designer visually renders control flow constructs. For example, a workflow with a condition and parallel branches looks like the the following sample:

View and edit component information
Section titled “View and edit component information”To view a component’s parameters, code, or other information, on the designer, select that component.
View and edit underlying JSON
Section titled “View and edit underlying JSON”To view the entire workflow’s underlying JSON alongside the designer, on the bottom toolbar, select Code. Changes that you make in one view instantly appear in the other.

Save and run workflows
Section titled “Save and run workflows”All the edits you make to a workflow stay in a draft version until you publish. Drafts let you iterate without affecting the workflow running in production. When you publish, the runtime picks up the new workflow definition, the draft becomes the live version, and the next trigger fires the latest version.
To run a draft workflow with a test payload before you publish, see Test for missing setup details.