Build Your First Workflow

Your first workflow should be small, concrete, and easy to verify.

This guide uses a simple pattern: read something, decide something, then produce an output.

Pick one repeatable task

Choose a task you already understand.

Good first workflows:

• Summarize new items from a connected app.
• Check a folder for documents that need review.
• Classify incoming requests.
• Create a weekly status update.
• Ask for approval before updating a tracker.

Avoid starting with a large end-to-end business process. Build one useful slice first.

Describe the outcome

Tell Gondo what should happen in normal language.

For example:

Build a workflow that checks my finance Gmail for invoice emails each weekday,
extracts the supplier name and amount, asks me to approve anything over GBP 500,
and then adds the result to the finance sheet.

Include:

• The trigger or schedule.
• The integrations involved.
• What data should be read.
• What output should be produced.
• When a human should review or approve.

Let Gondo choose the steps

Gondo may use different node types for different parts of the workflow.

• A trigger checks when the work should start.
• A task node reads messy input, such as emails or documents.
• A code node writes structured data to a sheet or API.
• A human node pauses for approval.

You can ask Gondo to explain the draft before publishing it.

Test with one run

Before trusting a workflow, run it on a small real example.

Check:

• Did it use the right integrations?
• Did it read the correct source data?
• Did it return the fields you expected?
• Did it pause where a human decision was needed?
• Did it avoid making changes before approval?

Refine the weak spots

Most first drafts need small edits.

If the agent guessed too much, make the task instruction stricter.

If a downstream step failed, check whether the previous step returned the expected field.

If the workflow should not proceed automatically, add a human node.

If a code node failed because a field was missing, make that field required in the upstream schema or handle the missing case explicitly.

Publish when it is boring

A good workflow should feel predictable. It should start at the right time, use the right accounts, produce clear output, and pause when judgement is needed.

When the test run looks boring in the best way, publish it.