# Build a workflow from a goal (/docs/guides/outcome-workflows) A workflow saves a repeatable way to accomplish a result. Start with what you want to happen and how you will recognize success. Ductor translates the request into steps you can review before you authorize a published version to run. You need access to a workspace, permission to create and publish workflows, and an available AI provider for guided creation. Work that uses another service also needs an executable connector action and an authorized connection. An entry in the connector catalog alone does not establish that an action can run. ## Describe the result [#describe-the-result] Open **Workflows**, choose **Create workflow**, and use **Guided** creation. Describe the outcome as you would explain it to a colleague. Include the evidence you expect to see when the work is complete. For example, “Prepare a greeting using the person's name and return it for me to review” identifies both the work and the result you will check. Answer the constraints that affect the work: | Choice | What to explain | | ---------------------- | ---------------------------------------------------------------------------------------------- | | Success | What must be true, and which result proves it? | | Inputs and connections | Where does the information come from? Which connected services may the workflow use? | | Allowed actions | May it only read and prepare work, or may it send messages, update records, or spend money? | | Limits | What spending, execution, waiting, and retry limits are acceptable? | | Human decisions | Which action must wait for someone to approve it? What should rejection do? | | Outputs and failures | What should the workflow return or save? Should it stop, retry, or request help when it fails? | Start with a small workflow that you run yourself. Add schedules, events, external actions, and AI tool use after you can recognize a successful result. The four main fields ask for your goal, success evidence, supplied information, and expected result. Open **Actions, spending, limits, and approvals** when you need to change permissions or execution bounds. Choose **Use supplied information only** for a workflow that transforms the data you enter. If you choose a connection, select the specific actions you allow. The guided controls set maximum attempts per step, seconds per work step, and output tokens per AI step. Connected actions must be declared safe to retry before you can allow multiple attempts. AI work is optional; proposing a workflow still uses the configured AI service. Proposal generation and AI or provider execution use the account's billing controls. This form does not set a dollar spending cap. Guided work supports data transformations, waits, individual AI calls, approval steps, and selected connected actions, with up to twenty steps. Agent tool loops, subworkflows, and schedules need the advanced authoring path. Human decisions use an eligible workspace role and appear on the run page. Generated gates wait up to twenty-four hours and stop when the decision times out. Choose **Propose work** once the essential fields are complete. If Ductor asks for clarification, answer the question in the relevant field and propose again. ## Review the proposed work [#review-the-proposed-work] Review **Proposed work** and the purpose of each step before saving the draft. Check that the proposal uses the inputs you actually have, includes the output you need, and places approval before any action that requires it. To correct the proposal, explain the change in **What would you like to change?** and choose **Revise proposal**. Review the new proposal before choosing **Save draft**. A message about a missing capability or connection needs to be resolved before publishing. Save only a proposal you understand. Saving creates a reusable **draft**; it does not authorize execution. A request such as “spend no more than five dollars” is a requirement for the proposal. Check that the relevant action or AI step has an enforceable control before publishing. A sentence in the description does not enforce a limit. ## Validate and preview [#validate-and-preview] Open **Preview** and choose **Check workflow**. The check reads the saved draft, so finish saving edits first. Review the reported issues; a draft can retain unfinished work, while publishing refuses an invalid definition. Choose **Revise with AI** to describe a correction, review the replacement work, and choose **Save revised draft** before checking again. Enter representative sample information in the named input fields and choose **Preview with these inputs**. Preview uses Ductor's data transformation runner and shows each supported step's status and output. It can reveal a problem with the input even when the definition passes its check. Preview does not call external services or an AI provider, approve human decisions, or fast-forward a wait. If the workflow reaches unsupported work or a wait, review the explanation instead of treating the preview as proof that the whole workflow succeeded. A rejected preview leaves the saved draft available for revision. ### Resolve a useful validation failure [#resolve-a-useful-validation-failure] If a generated transformation refers to an unsupported function, **Check workflow** reports a validation issue. Describe the repair in **Revise with AI**: “Fix the reported validation issue using supported transformations. Keep the same inputs and expected result.” Review and save the corrected draft, then check it again. Correcting the draft leaves any published version intact. If a preview reports that a referenced name is missing, inspect the sample input. Supply the name and preview again. Missing required fields are caught by the input form before execution; a missing optional field used by a transformation can fail during preview. An input correction does not require another published version. A change to the work itself does. ## Three reusable starting requests [#three-reusable-starting-requests] Create each request as its own workflow and save the reviewed draft. The proposed steps can vary with the AI provider, so check the result rather than relying on a particular number of steps. Use **Use supplied information only** and leave AI execution disabled for the first two. ### Prepare a greeting [#prepare-a-greeting] “Prepare a greeting using the person's name. Return the greeting so I can check it before sending anything.” Supply a person's name. Set success evidence to “The returned greeting includes the supplied name and nothing is sent.” Set the expected result to the greeting. Preview with **Alex**, inspect the returned greeting, then authorize publication and start a run. Compare the recorded result with the preview. Run the same published workflow with a different name to reuse it. ### Shortlist leads [#shortlist-leads] “From supplied leads, keep people who want to buy within 90 days, remove duplicate email addresses, and return the top three by budget.” Supply a list of leads with an email address, budget, and number of days until they plan to buy. Set success evidence to “At most three unique email addresses, each within 90 days, ordered by budget from highest to lowest.” State how to choose between duplicate records. The example below retains the first admitted record for each email address. Use sample leads that include a duplicate email, someone outside the timeframe, and more than three eligible people. Add the rows in the preview input form and check every part of the evidence: | Email | Days until buying | Budget | | ----------------------------------------------- | ----------------- | ------- | | [lee@example.test](mailto:lee@example.test) | 30 | 500000 | | [sam@example.test](mailto:sam@example.test) | 60 | 700000 | | [lee@example.test](mailto:lee@example.test) | 20 | 900000 | | [later@example.test](mailto:later@example.test) | 180 | 1000000 | | [jo@example.test](mailto:jo@example.test) | 90 | 600000 | | [ari@example.test](mailto:ari@example.test) | 45 | 400000 | With first-record duplicate handling, the result is Sam, Jo, then Lee, with budgets of 700000, 600000, and 500000. The later Lee record is a duplicate, and the person buying in 180 days is outside the timeframe. To revise the timeframe, choose **Revise with AI** and ask to change ninety days to sixty. Save, check, and preview the draft before explicitly publishing the new version. Earlier runs retain their version. ### Review a recommendation [#review-a-recommendation] “Prepare a recommendation from supplied details, wait for an authorized reviewer, and only then prepare the approved result. Stop if rejected.” Explain the details you will supply and what the recommendation should contain. Choose an eligible reviewer role under the approval controls, such as **Operator**. If the recommendation requires AI inference, explicitly allow AI work and choose its output limit. Review the proposal to ensure the human decision precedes the approved result. Preview checks the supported work and reports that it is waiting for a decision; it does not approve on your behalf. Publish deliberately, start a run, and choose **Inspect run**. The run presents **Decision needed**, its deadline, and a **Decision note** field. Completed step results appear above the decision, so you can inspect the prepared recommendation before choosing **Approve** and **Confirm approval**, or **Reject** and **Confirm rejection**. For sample details, use “Call the customer to confirm the budget before assigning an agent.” Approval lets the final result contain that recommendation with an approved status. Rejection stops the approved branch. The server checks your identity against the workflow's saved audience. If your role is not eligible, the decision remains pending and the page tells you to ask an eligible reviewer. ## Authorize publication [#authorize-publication] Check the graph against your success criteria as well as the validation result. A structurally valid workflow can still perform the wrong work. Confirm the connections, actions, approval placement, and limits before choosing **Publish**. In **Review publication**, check the workflow and preview your sample input again. Publication needs a passing check and either a completed preview or an explicitly limited preview that stops at external work or a wait. Fix an execution failure before proceeding. Confirm that the version may perform the described work, including any steps preview could not execute, then choose **Authorize and publish**. The server performs its final publication checks before creating the version. If someone changed the draft after your review, refresh and review the latest draft. Publishing creates an immutable version. The draft remains available for further editing. Later edits do not change the version a run already uses. ## Run and inspect the result [#run-and-inspect-the-result] Choose **Run** to open **Run published workflow**. Fill in the named fields or add rows to a list, then choose **Start run**. The editor resolves the published version rather than executing your editable draft. A live run can update services or send messages, so start with sample data and connections intended for testing when effects are involved. Choose **Inspect run**, or use the editor’s **Activity** panel to find it later. On the run page, inspect **Activity**, **Inputs**, and **Outputs**. Compare the recorded result with the evidence of success you specified. A successful status does not by itself prove that the returned information meets your requirements. When a run waits, identify what it is waiting for before starting another run. A pending human decision, a scheduled wait, a retry, and a failure require different responses. Use the run's events and step state to find the next action. ## Revise or recover [#revise-or-recover] To change future behavior, choose **Revise with AI**, describe the change, review and save the revised draft, check and preview it, and explicitly publish another version. Verify that version with a new run. Keep the previous run and published version as evidence of the behavior that actually occurred. For execution failures, first inspect the failing step's input, result, and attempt history. If the greeting fails because an optional name was left blank, return to the workflow, start a new run with **Alex**, and inspect its successful result. The failed run stays available as evidence. Correct an expired connection or unavailable service before requesting more work. Check whether an external effect happened before retrying an operation that could create duplicates. **Redrive** asks the coordinator to re-evaluate ready steps in an active or paused run. It can help with a stranded run; it does not rewrite a terminal failed run or switch an existing run to your new draft. A revised workflow needs a new published version and a new run. For integration and operator details, see [workflow definitions and run controls](/docs/management/workflows), [connector connections](/docs/guides/add-connector), and [AI workflow steps](/docs/ai/workflow-ai-steps).