Prompt-to-workflow

What is prompt-to-workflow?

Prompt-to-workflow is describing an automation in one or two sentences and letting the tool assemble the flow for you. You type something like "when an invoice arrives in the accounting mailbox, save the attachment to SharePoint and post a message in the bookkeeping channel", and a few seconds later a flow is on screen with a trigger, a handful of actions and the connectors already picked.

Every large automation platform has a version of this. In Power Automate the entry point is called Describe it to design it, and Microsoft's documentation says Copilot generates the structure for your flow based on your description, where that structure contains a suggested trigger and one or more actions. The AI Workflow Builder in n8n takes a plain-language brief and handles node selection, placement and configuration. Zapier has Copilot, which works with you to build the Zap from your description and keeps chatting about the parts it got wrong.

The word carrying the weight in all three descriptions is structure. What comes back is a draft with the shape of the automation in it, and almost none of the decisions that keep one running after the first week.

What the builder produces, and what it leaves for you

In the first version you reliably get the trigger, the connectors, the steps in a plausible order, and some of the parameters. Power Automate's documentation is honest about that last one: the AI might not fill in some parameters, even if you provided them in the description.

What is missing is the part that takes the time. Nobody has decided what happens when the mail carries two attachments instead of one, which account the flow runs as, who else is allowed to edit it, whether a failed step gets retried or stopped, or who finds out that it failed. Exceptions, permissions, retries and failure routing are the bulk of the work in any automation that runs unattended, and a generated draft contains none of them.

The vendors say as much in their own documentation. Microsoft's responsible AI FAQ for Copilot in cloud flows states that all changes done by Copilot should be reviewed in the designer, and that Copilot is not equipped to help with fixing flow errors. Zapier tells you to thoroughly test your workflows before running them live, to prevent things like unintentional Zap loops or incorrect steps. In n8n the third step, after describing and building, is review and refine.

This is why the first ninety seconds feel so much better than the two days that follow. The generator is quick at the part that used to be tedious: finding the right trigger, remembering which connector holds the action you want, wiring them together. It is not quick at the part that was always the actual project, because that part is a series of business decisions and nobody told the model what your business decided.

What makes a description produce a usable draft

The difference between a draft you can build on and a draft you throw away sits almost entirely in the prompt, and specifically in four things being named in it.

• The trigger. Say what starts the flow and how often that happens. "When a mail arrives in facturen@" is a trigger. "For incoming invoices" is not.

• The systems. Name the products. Microsoft's own prompt guidance asks you to mention the connector by name: Outlook, Teams, Forms. A description that says "our accounting package" gets you a draft that guessed.

• The decision points. Say where the flow branches and on what value. Above 500 euro the owner has to approve it, below that nobody does.

• The failure case. Say what should happen when the file cannot be written or the supplier is not in the system. Name it and at least a branch appears that you can then correct.

Write those four things down and look at what you have on the page. It is a small specification: an event, the systems involved, the rules, and the unhappy path. That is the same argument behind spec-driven development on the coding side. The tool changed. The thinking did not move anywhere.

A generated invoice flow, and the five things a person added

A technical wholesaler with forty staff wants supplier invoices out of a shared mailbox and into SharePoint. The operations manager types: "When an email with a PDF attachment arrives in facturen@, save the attachment to the SharePoint library Inkomende facturen and post a message in the Teams channel Boekhouding."

The draft comes back inside a minute with four blocks: a trigger on new mail, a condition on the mail having an attachment, a create file action pointed at the library, and a post message action pointed at the channel. Somebody signs the connections in, tests with one mail, and it works. Then it goes live, and over the next two days these five things get added.

1. A filter on what counts as an invoice. The trigger fires on every mail in that mailbox: out-of-office replies, the supplier's newsletter, the delivery note a driver photographed. The generated condition only checks whether an attachment exists at all. Somebody had to check the sender domain and the file extension, and decide what happens to everything that does not pass.

2. A file name that does not collide. Three suppliers send an attachment called factuur.pdf, and the create file action fails on the second one because that name is already in the library. Somebody had to build the name out of the supplier, the invoice number and the date, and decide what a repeat does to the older file.

3. A path for failure. By default an action only runs when the step before it finished with the status Succeeded, so when the SharePoint step fails the Teams message is quietly skipped and the run ends red in a history nobody opens. Somebody had to group the steps in a scope, add a step set to run after that scope has failed, and have it post the mail subject and the run link somewhere a human reads.

4. The identity the flow runs as. The generator signed the connections in under the account of the person who typed the prompt. Power Automate documents that a cloud flow uses the plan of its owner, and that it drops back to the low performance profile once that owner leaves the organisation. Somebody had to move the connections to a service account and add a second owner.

5. Who can read the library. The SharePoint site the draft picked was the one the operations manager happened to have open, and everyone in the company could read it. Supplier invoices carry bank details and payment terms, so somebody had to move the library, set permissions on it, and check that the flow's account still had write access.

The same flow, hand-built, the first time it fails

The dimension that separates a generated flow from one somebody built on purpose is what exists at the moment of the first failure.

• Who finds out, and what they are told. With the generated draft, the run is marked failed in the run history, somebody has to go and look, and what they find is the platform's error text with a link to the run. With the hand-built flow, a message lands in the channel the bookkeeping team already reads, naming the supplier, the invoice number and the step that broke.

• What the rest of the flow does. The generated draft skips every step after the failed one, because the default is to run only after success, so the Teams message never goes out either. The hand-built flow runs its catch branch and moves the invoice to an exception folder.

• What happens if nobody notices. Power Automate turns a flow off after 14 days of continuous errors, so the generated draft goes quiet on its own and the invoices sit unread in the mailbox. With the hand-built flow the alert repeats and the queue grows where people can see it.

Retries sit underneath all of that. Power Automate applies a default retry policy to connector operations: up to twelve retries at exponentially increasing intervals on the medium and high performance profiles, and up to two on the low profile. Those retries only fire on transient failures, the timeouts, the throttling and the server errors. An expired token comes back as an authentication error and is not retried at all, and a duplicate file name is not transient either. Which failures deserve a retry, which deserve a stop and which deserve a person is a business call, and the generator has never made one.

The person who knows the process can now build it

One thing here is genuinely new. The warehouse supervisor who knows that the delivery note has to be matched before the invoice is booked can now produce something that runs, on the same afternoon the annoyance came up. That is the gain a citizen developer already got from a low-code platform, arriving earlier in the process.

The gap is that knowing a process and running a piece of software are different skills. The supervisor knows exactly which invoices need a second signature. He does not necessarily know that a connection is a stored credential with an expiry date, that the flow will stop the day the token goes stale, or that the same mail arriving twice books the invoice twice unless something checks. That is not a criticism of him. It describes what a builder hands over: the visible logic, without the operational contract underneath it.

What you arrange before you open it up to everyone

A company can go from five automations to fifty in a quarter this way. Not through recklessness, just through it being easy. Fifty automations with no inventory, no named owners and no error routing is shadow IT running at speed, built with sanctioned tools inside the sanctioned tenant, which is what makes it hard to spot. In Power Platform the feature is on by default in the supported regions, and switching it off is a tenant-level action that runs through Microsoft support, so banning it is not the cheap option either. Four things take the edge off.

1. An environment where building is allowed. In Power Platform, environment routing is a tenant-level setting, off by default, that sends makers into their own personal developer environment instead of the shared default one. Turn it on and experiments stop landing in the environment everybody depends on. Connector policies then decide which connectors may sit together in one flow, and a flow that breaks a policy is suspended rather than left running.

2. An owner per flow, written down. Not the creator by accident, an owner on purpose, plus a second person who can take over. This is the cheapest of the four and the one most often skipped, because on the day you build something the question of who maintains it feels theoretical.

3. A shared error mailbox or channel that somebody actually reads. One destination for every automation's failures, watched the way the general mailbox is watched. A failure notification that only reaches the person who built the flow stops working the moment she goes on holiday.

4. A review rule for anything touching money or customer data. Payments, credit notes, prices, personal data, anything a customer sees: a second pair of eyes before it is switched on. Zapier builds this into its Enterprise plan as publishing restrictions, where a member has to request approval from a super admin or the account owner before a Zap goes live. If your platform has no equivalent, the rule works fine as an agreement between people.

What to watch out for with prompt-to-workflow

A generated flow still has to be read, and a flow is harder to read than code. A reviewer opening a pull request sees the logic in one column of text and can search it. A reviewer opening a flow sees a diagram, has to expand every action to see its settings, and finds the run-after behaviour and the retry policy two clicks down inside each one. The reviewing is not optional and it takes longer than people expect.

Preview is not the same as finished. Describe it to design it in Power Automate is still labelled preview, supports English descriptions only, and works for cloud flows and a subset of connectors. Zapier's help documentation calls Copilot an open beta. The Copilot inside the cloud flow designer carries no preview label. Check which one you are relying on before you plan a rollout around it.

Treat it as the prototype, not the delivery. For a smaller company the honest reading is that this is an excellent way to find out whether a flow is worth building at all. Describe it, look at the draft, run it once by hand, and you have learned in ten minutes what a specification meeting argues about for two weeks. Then build the version that has to survive: the exception path, the owner, the permissions, the alert. The draft did the cheap thinking about connectors and triggers. It did none of the thinking about Monday morning.