Maestro Automate: the parts of a workflow, from trigger and nodes to testing, deployment, and run history, shown on one order intake example.

Maestro Automate is a UiPath product for building workflows in which AI agents and APIs work together. A workflow is a series of steps that runs when you start it, on a schedule, or when something happens in another app. This page follows one workflow, order intake, from its first node to its run history, so you can see what each part of Maestro Automate does.

An online store receives orders from customers. Before accepting an order, the store wants to know two things: are the items in stock, and is the customer's credit good? Accepted orders go into the customer relationship management (CRM) app. The rest go to a sales representative, who follows up with the customer.

Done by hand, that is two lookups and a decision for every order. In Maestro Automate, it is one workflow:

Each box is a node. Each node does one job and passes its result to the nodes after it. The lines between nodes are edges, and they set the order in which the nodes run. You build all of this on the Flow canvas, a visual workspace, either by describing the workflow to a coding agent or by adding nodes yourself.

You'll use: New order, a Manual trigger.

Every workflow starts with a trigger, which decides when the workflow runs: when you start it, on a schedule, or when something happens in another app. In the example, New order is a Manual trigger: each run receives one order's product ID and customer ID as inputs. In a live store, a connector trigger could start the workflow whenever an order arrives instead. Each order starts its own run of the workflow, so ten orders mean ten runs.

Triggers lists the trigger types.

You'll use: Check stock and Check credit, two HTTP Request nodes.

An HTTP Request node calls the API of another system. Check stock asks the inventory system whether the items are available, and Check credit asks the credit system about the customer.

Each answer becomes the output of its node. Nodes don't share data automatically, so a later node reads an earlier node's output through an expression, for example $vars.checkStock.output.body for the response of Check stock. Variables and data flow describes how data moves between nodes.

You'll use: Review order, an Autonomous agent node.

An agent is an AI model that you give instructions and tools. Instead of following fixed rules, it reads the order and both answers, then decides whether to accept the order. You can add guardrails to an agent, which are rules that screen what it receives and returns, for example to keep personal data out of its prompts.

Add an AI agent to a workflow shows how to set one up.

You'll use: Accepted?, a Decision node, then Create order in CRM, a Script node that stands in for a CRM connector, and Notify sales rep, a Slack connector node.

A Decision node checks one condition and sends the run down one of two paths. When the agent accepts the order, Create order in CRM records it. When it doesn't, Notify sales rep posts a message to the sales representative in Slack.

Notify sales rep uses a connector, a ready-made integration with another app, so you don't write the API call yourself. It signs in to Slack through a connection, your account for that app. Connector lists every connector, and Slack describes what the Slack connector can do.

You'll use: Run Debug (▶) in the bottom toolbar of the canvas, which starts a debug run.

Before anyone depends on the workflow, you test it. Select Run Debug, enter the trigger's inputs when a dialog asks for them, and the workflow runs on the canvas with sample data. In the example, you run it with a sample order:

An agent can answer differently each time it runs, even for the same order. Evaluations check that the agent stays reliable across runs. You collect sample orders with the decision you expect, run them all through the workflow, and compare the results. Run them before you deploy, and again after you change the agent's instructions or model. Evaluations describes how to set them up.

Debugging basics covers the testing tools in detail.

When your tests and evaluations give the results you expect, you deploy the workflow. From then on, every new order starts a run, without you opening the canvas.

Deploy a workflow describes the steps.

Each run must finish within 24 hours, and up to 50 runs can be in progress at the same time. Limits and fair use describes the limits. For processes that wait longer, such as several days for a human, Convert to Maestro Orchestrate describes when to move a workflow to Maestro Orchestrate.

If a step fails, for example because the CRM is unavailable, the run pauses at that step and waits for you. When the CRM is back, you retry the run from the failed step, or you cancel it. Retry and cancel describes how. You can also connect the node's error path to other steps, such as a message to the team, so the workflow handles the failure itself. Error handling describes how.

Maestro keeps every run for 30 days after it ends. For each order, you can see what started the run, which path it took, and the data and timing of every step. Monitor runs describes how.

Every workflow goes through the same five stages, and the same workflow file is used in all of them, so what you test is what runs after you deploy.

The order intake workflow uses a few kinds of nodes. The Add node panel has more, grouped by the kind of work they do:

The quickest way to build is to describe the workflow to a coding agent, such as Claude Code or Codex, and let it build the workflow for you. Set up your coding agent gets it ready in three steps.

To build on the Flow canvas yourself, use VS Code, Studio Web in your browser, or Studio Desktop. The canvas is the same in all three. Where to build compares them.