Create your first workflow

This quickstart turns one automation idea into a reviewed Workflow Agent draft and a no-write simulation. It does not activate a workflow or contact an external app. By the end, you should have an ordered definition, identified app requirements, visible route and approval gates, and a simulation result that explains what would happen under the current preview model.

Prerequisites

Choose a small workflow with a clear trigger, a small amount of data, and one destination action. A first draft is easier to inspect when the desired outcome can be stated in one or two sentences. Avoid combining several branches, exception policies, or unrelated app pairs; a general visual branch editor is not verified in the current builder.

You need access to Workflow Agent and enough knowledge of the source and destination apps to describe their roles. You do not need to supply live credentials merely to create a draft. However, the builder may report that a connection or credential is required before a route could move beyond preview.

Before starting, keep these boundaries in mind:

• the app directory can be loaded from production-derived data or a fixture fallback;
• a detected app does not prove that its actions are executable;
• bridge, HTTP, webhook, MCP, native, and generated-connector routes have different readiness states;
• approval packets and run records are previews;
• activation remains locked even when the draft passes its visible checks.

Open the workflow builder from the Workflow Agent home surface. The build route can accept a prompt, so the description may be carried into the draft screen.

Describe the workflow

Write the desired outcome in operational terms. Identify the event that starts the process, the information that should move or change, and the app that should receive the result. For example, describe that a new item in one app should create a corresponding item in another. Do not include real secrets, access tokens, or sensitive payloads in the description.

A useful prompt answers four questions:

1. What event should be observed?
2. Which app supplies the source data?
3. What action should occur next?
4. Which fields or conditions are important to the result?

Submit the description to create a deterministic draft. The expected result is a builder view containing detected apps, ordered steps, route-readiness information, and a workflow-definition preview. If the description is too broad, revise it so each step has one purpose. If an app name is ambiguous, use the app’s recognizable product name and explain whether it is the source or destination.

The prompt is an instruction for drafting, not permission to execute. Workflow Agent explicitly states that no external system is contacted while the definition is being constructed.

Review detected apps

Check that the proposed source and destination match your intent. App detection is based on the currently loaded app and app-pair data. When the production-derived source is unavailable, the loader can use a fixture fallback; that may reduce the available suggestions.

For each detected app, separate three questions:

Route status and execution route are not interchangeable. A status such as bridge_available or api_mcp_possible describes readiness. An execution-route value such as zapier_bridge, http_api, mcp, or generated_connector identifies a possible mechanism. Neither guarantees that the current environment can use it.

If the wrong app was selected, return to the description and make the role explicit. If the correct app appears with suggested_only or coming_soon, continue only to understand the draft; do not reinterpret the status as live support.

Review the draft

Read the steps in order and confirm that each one advances the requested outcome. A well-formed draft should expose its trigger or starting event, transformations or checks, and destination action without hiding intermediate work.

Inspect the inputs attached to each step. Values can come from the original description, detected app data, or outputs expected from an earlier step. The current builder also renders a read-only JSON definition. Use that representation to compare the visible step list with the structured workflow; do not edit the JSON as though it were a live configuration file.

Pay particular attention to:

• the action assigned to each app;
• mappings between source and destination fields;
• route status and the candidate execution mechanism;
• any needs-setup, config-preview, dry-run, live-blocked, or disabled state;
• approval requirements before a sensitive action;
• validation messages that prevent simulation.

The builder may display an activation checklist. Treat it as an explanation of gates, not as a promise that activation becomes available after every item is checked. The inspected implementation keeps live execution blocked for this milestone.

Resolve missing connections

A missing connection means the draft depends on an app identity or provider credential that is not available to the current configuration. It does not invalidate the conceptual workflow, but it can prevent route validation or simulation.

Open the integrations surface to inspect the relevant connection. The current interface groups credentials, bridge providers, generated connectors, native connectors, MCP servers, and webhook or API-route concepts. Confirm that the required app and route appear, then read the state shown for the connection or credential.

Do not infer more than the state supports. configured indicates that configuration data exists; it does not guarantee a successful external request. needs-setup calls for additional configuration. expired means the credential cannot be relied upon. config-preview, dry-run, live-blocked, and disabled all prevent a live interpretation.

This quickstart does not require you to add a real secret. Exact credential storage, encryption, rotation, and retention behavior remain under security review. If the simulation can proceed with a preview route, keep the draft in that mode. If the builder requires a credential and none is available, the correct outcome is a documented setup gap rather than a fabricated connection.

Run a simulation

Request a simulation only after the detected apps, steps, and visible prerequisites match your intent. The simulator evaluates the draft without making external writes. Depending on the route, the result may include a bridge dry-run, a policy decision, missing-credential information, or a preview of expected step outputs.

A useful simulation result should let you answer:

• Which steps were evaluated?
• Which route was considered for each app interaction?
• Were any credentials or approvals missing?
• Did policy or route readiness block progress?
• What evidence or read-only definition was produced?

Review the result alongside the original draft. A passed simulation means the preview logic accepted the current definition; it does not verify a provider call, a remote side effect, webhook delivery, MCP execution, schedule, or durable run. Approval data remains a packet preview, and current Workflow Agent run records are local-safe or fixture-backed.

When the simulation reports a failure, preserve the draft and correct the specific cause. Revise an incorrect step, clarify the app description, address a visible setup requirement, or accept that a route is not available. Do not bypass a policy or approval gate. The endpoint of this quickstart is the simulation record and its evidence. Live activation is not part of the supported procedure.

Keep the first draft small

A narrow workflow makes it easier to distinguish a drafting problem from an integration problem. Start with one trigger and one destination action. If the description includes approval, filtering, scheduling, and several destinations at once, the builder may produce a plausible sequence without proving that all control flow exists. Record secondary behavior after the main path is understood.

Use non-sensitive sample values when the draft needs data to illustrate a mapping. The example should be recognizable enough to expose missing fields but should not contain customer information, access tokens, or production payloads. Simulation output remains preview material and should be labeled accordingly.

Interpret the activation checklist

The activation checklist communicates why execution is unavailable. A draft can be complete while route status remains suggested. A simulation can pass while an approval packet is unresolved. A connection can be configured while the connector is live-blocked. Review each gate independently instead of looking for a single green state.

If the builder shows all preview gates as satisfactory, stop at the simulation record. The current milestone does not turn that result into an Activate control. Saving the definition, recording the route and setup gaps, and sharing the simulation with a reviewer are the appropriate next actions.

Example revision cycle

A first prompt might identify the wrong destination app. Rewrite the description to name the source event and destination action explicitly, regenerate, and compare the new steps with the previous draft. If the correct pair is then found but marked suggested_only, keep the improvement while noting that the execution route is absent. This separates prompt quality from product availability and prevents repeated edits from hiding a genuine route limitation.

Confirm each mapping

For every value that moves between apps, identify the source field and the destination field. If the builder uses a generic label, add enough context to the workflow description for a reviewer to understand the mapping. Do not state that Workflow Agent validated a remote schema; the current preview only shows the draft’s representation.

When a destination requires data that the source does not provide, choose whether to remove the requirement, add a supported intermediate step, or leave the mapping unresolved. A simulation that fabricates a value would hide a real implementation gap.

Review route alternatives without selecting a live path

The loader can present more than one candidate mechanism, such as a bridge, native connector, HTTP API, MCP, or generated connector. Compare them by current readiness, not by familiarity. A route marked config preview can be more informative than a suggested-only path, but neither should be described as executable.

If the draft changes route after an edit, repeat connection and approval review. A different mechanism may require another credential or governance boundary even when the business outcome is unchanged.

Capture the final preview

At the end of the quickstart, retain the workflow description, ordered steps, route state, visible setup gaps, simulation summary, and evidence references. This package is enough for a product or implementation review without implying that anything ran. Do not include raw secrets or claim that a recent-item card is durable history.

Final review before handoff

Read the draft as another operator would. The trigger, app roles, step order, mappings, route state, connection gaps, approval needs, and simulation outcome should be understandable without access to the original conversation. If any item depends on unstated context, revise the description and simulate again. The final artifact is a reviewable proposal, not an activated workflow.

Stop conditions

End the exercise when the draft reports an unavailable route, missing configuration that cannot be added through a verified control, or a disabled governance step. Recording the stop condition is part of the quickstart result. It prevents the reader from treating persistence or repeated simulation as a substitute for activation.