Skip to content
Expedify
Start free
Expedify in an Afternoon
Course contents

Module · Doing the same things by conversation

Building a workflow by asking

Lesson 35 of 40 · 6 min

Reading and writing records is useful. Building something that runs by itself is a different order of thing, and it is where a partner's afternoon actually goes.

One sentence

You: Build me a workflow: when an enquiry over fifty lakh comes in, raise a high-priority task to review it that day.

What came back was a workflow with 3 nodes, named, described, and — read the product's own reply — a draft:

Created draft workflow '[COURSE] Flag a large enquiry'. It will not run automatically until activated; you can test it now (workflows:run).

It will not run until somebody switches it on. The same safety property you met in Draft and active: which workflows are actually running, and it holds here for exactly the reason it holds on the canvas: building is not deploying. You can ask for twenty workflows in an afternoon and none of them touches a customer.

The two questions to ask every single time

You: Is it actually runnable?

"valid": true,
"runnable": true,
"errors": [],
"warnings": []
The answer, from the capture on 2026-08-19.

Valid and runnable are two different claims, and you want both. Valid means it is a well-formed workflow. Runnable means it has a trigger, its references resolve, and there is a path from that trigger to something that does work. A workflow can be perfectly valid and never do anything.

You: What did it wire up?

And it hands back the specification it produced, along with the node count and the status — draft, 3 nodes. That is not a summary of the workflow, it is the workflow.

Then open the canvas

This is the habit that separates a partner from somebody demoing a party trick. What came back validated. It still may not be what you meant — a threshold on the wrong side of a comparison, an arm wired to the wrong step, a condition that can never be true. All of those are valid, runnable, and wrong.

You already know how to read one: The three parts of a workflow for the shape, Reading a node's configuration for the boxes, Conditions and branches for the arms. Thirty seconds on the canvas after every build.

Getting from nothing to a working draft in a sentence

What the canvas is for
Seeing what it actually wired

Boring, repetitive structure you would rather not drag

What the canvas is for
The one node whose value you want to argue with

A second and third variation to compare

What the canvas is for
Handing it to a client's team to maintain

What it is genuinely good for

  • The first draft. Ninety per cent of a workflow is structure nobody enjoys assembling. Ask for that, then spend your attention on the ten per cent that is judgement.
  • The same thing across clients. A workflow you have built once is a paragraph you can send again, adjusted. It is the closest thing a partner has to a template that is not a template.
  • Reading one back. Ask what an existing workflow does and you get a description of the real thing, which is a faster way into somebody else's org than clicking through nineteen canvases.

Change one thing — build one, check it, throw it away

  1. Ask for a workflow you would actually want: something small, with one condition in it.
  2. Ask whether it is runnable, before you look at anything else.
  3. Open it on the canvas and find one thing you would have done differently. There will be one.
  4. Delete it. You are practising the loop, not building an org.
  5. Do not activate anything you built this way today.

Try it

  1. Describe a workflow badly on purpose — vague about the threshold — and see what it chooses. Then decide whether you would have caught it without opening the canvas.
  2. Ask it to describe one of the org's nineteen back to you, and check the description against the canvas.

Next: Building an agent by asking — the same sentence, for something that decides rather than follows rules.

Sign in to track progress