Bringing AI into a flow with AI Builder

What AI Builder actually adds

Everything you've built so far has been deterministic: the same input always produces the same output, because every step follows a fixed rule. A trigger fires, an action runs, a field maps to a column. That's exactly what you want for logging, filing and alerting: predictable plumbing.

But some steps aren't plumbing; they're judgements. Is this incoming message a complaint or a thank-you? What's the customer's account number buried in this paragraph? Which of our four teams should pick this up? A human does that in a second and can't tell you the rule. A plain flow can't do it at all: there's no field that says "sentiment", no column called "urgency".

AI Builder is Microsoft's AI feature for Power Platform, and inside a flow it shows up as ordinary actions you drop between your other steps. Broadly it offers two kinds:

Prebuilt models. Ready-made AI for common jobs: category classification, entity extraction, key-phrase extraction, sentiment analysis, language detection, and document jobs like reading an invoice or a receipt. You don't train anything; you feed text or a file in and read structured output back.
Prompts. You write an instruction in plain English ("summarise this email in two sentences", "classify this message as Billing, Technical, Praise or Other") and the AI returns text you can use downstream. These behave much like a prompt to any chat tool, except the answer flows straight into the next action instead of onto your screen.

The important mental shift: an AI Builder step is the one step in your flow that can be confidently wrong. Everything around it is still rigid plumbing. So the skill isn't adding the step; it's building the flow so a wrong guess is caught, not shipped.

The Fernway scenario

We'll carry one job through. From the customer-feedback project brief, Maya wants every incoming feedback email captured, categorised and routed: Billing goes to Dan in Finance, Technical to Ravi in IT, and praise or general comments just get logged. Today someone reads each email and files it by hand, which is exactly why messages fall through the cracks. This is a real judgement ("which category?") sitting inside otherwise simple plumbing (log it, notify someone). That's the textbook case for one AI step.

Step 1: Trigger and get the content

The flow starts the ordinary way: a trigger of When a new email arrives in the shared feedback mailbox. Nothing AI about it yet. You grab the sender, subject and body as dynamic content, just as you would for any email flow. The AI only earns its place once you have some text that needs a judgement made about it.

Step 2: Add the AI step and prompt it

Now you add an AI Builder action. For a classification like this, a prompt is the most flexible choice: you describe the categories in plain English and feed in the email body. The prompt is written the same way you'd write any good instruction: role, task, the exact options, and the output shape.

AI Builder prompt: classify a feedback emailPower Automate

You are triaging customer feedback for Fernway Group. Read the email below and reply with exactly one word, the single best category from this list: Billing, Technical, Praise, Other. Do not explain and do not invent a category outside the list. If it fits none, reply Other.

Email:
[insert the email body as dynamic content]

Why this works: This reads like a good chat prompt because it is one: it names the closed set of categories, forbids invention, and pins the output to a single word so the next step can branch on it cleanly. A vague prompt ('what is this email about?') returns a sentence you can't route on, whereas a specific one returns a value you can.

The representative output is a single word, Technical, sitting in the step's output, ready to map into the next action. Because you constrained it to one word from a fixed list, you get something a condition can test, not a paragraph you'd have to parse.

If instead you needed a value out of the text (the customer's account number, say, or a renewal date), you'd reach for entity extraction rather than a prompt, because that's a prebuilt model built for pulling named things out of unstructured text.

AI Builder prompt: pull the key details outPower Automate

From the customer email below, extract three things and return them on three labelled lines exactly like this:
Account: [the account name or number, or "Not stated"]
Urgency: [High, Medium or Low based on the tone]
Summary: [one sentence, under 20 words]

If a detail isn't in the email, write "Not stated". Never guess or invent one.

Email:
[insert the email body]

Why this works: Asking for a strict, labelled shape ('Account: … / Urgency: …') turns messy prose into fields you can map. Telling it to write 'Not stated' instead of guessing is the single most important line; it stops the model filling a blank with a plausible invention that then gets logged as fact.

Step 3: Use the output, but guard it

Here's where a flow with AI differs from a flow without. You never let the AI's answer act unsupervised on anything that matters. Two habits do most of the work.

First, branch, don't assume. Add a condition on the category and route each branch to the right person, but include an explicit path for anything unexpected. If the model somehow returns a value outside your list, that email should still land somewhere a human sees it, not vanish.

Second, keep the human on the irreversible step. Logging the email to a list is safe to automate outright; worst case, a mis-filed row you can move. Replying to the customer is not: never wire the AI's summary straight into an outgoing reply. Route it to a person, or draft-and-hold, so a human approves anything that leaves the building.

Plain-English description of the whole flowPower Automate

When a new email arrives in the Feedback mailbox: run an AI prompt that classifies the body as Billing, Technical, Praise or Other. Add a row to the "Feedback Log" SharePoint list with the sender, subject, category and date. Then: if Billing, notify Dan; if Technical, notify Ravi; if Praise, just log it; for anything else, notify Maya to check by hand. Do not send any reply to the customer automatically; leave that to a person.

Why this works: Describing the flow end to end (trigger, AI step, branch, and crucially the 'anything else' fallback and the human check before any reply) is how you'd brief Copilot or a colleague. Naming the fallback and the held reply in the description means the safety isn't an afterthought bolted on later; it's part of the design from the first sentence.

Try it now

🛠 Try it now: Add one AI step to a real routing flow

Build a small flow that classifies incoming text and routes it. Use a manual trigger with a text input while you're testing so you can paste different messages in without waiting for real email. Add an AI Builder prompt that classifies the text into three or four named categories, then a condition that routes each category somewhere (a Teams message to yourself is fine) plus an explicit "anything else" branch. Keep to the Phase 0 privacy rules: never paste real customer or personal data into a personal or trial environment. If you've no safe material, use the Fernway email thread or invent three short feedback emails. A good result: you can paste in a message that clearly belongs in one category and watch it route there, and paste an ambiguous one and watch it fall to the human-review branch instead of being forced into a wrong box.

Common mistakes

Adding AI where a rule would do. If the decision is "does the subject contain the word invoice", that's a condition, not a job for AI; plain rules are free, instant and never hallucinate. Reach for AI Builder only when the judgement can't be written as a rule.
Letting the AI step act on the irreversible bit. Logging a mis-categorised email is recoverable; auto-sending a wrong reply to a customer isn't. Keep the human on anything that leaves the organisation or can't be undone.
No fallback branch. If you only handle the categories you expect, an unexpected answer disappears silently. Always route "anything else" to a person.
Ignoring the running cost. AI Builder is a premium capability that consumes credits or capacity each time a step runs. A flow that classifies every email in a busy mailbox can burn through an allowance fast, so check what your environment is licensed for before you switch it on at scale.
Over-trusting the guess because the flow ran green. This is the big one. A classification step returns a confident single word whether it's right or wrong, and the flow logs it either way with a reassuring green tick. The tick means the step ran, not that the category is correct; an angry complaint mislabelled Praise files itself perfectly and is never chased. Spot-check the AI step's real answers against the real inputs, especially early on, and never treat "the flow succeeded" as "the AI was right".

Keeping current

AI Builder's model names, prompt experience and licensing move quickly, and Microsoft has been shifting text jobs from older "generate text" models towards the newer prompts experience, so check the current picture rather than trusting a remembered menu. Microsoft's AI Builder in Power Automate overview and Get started with prebuilt prompts on Microsoft Learn track what's available now. The design principle is durable, though: one AI step, guarded by a fallback and a human check, will be the right shape long after the menus change. Accurate as of 13 July 2026.

By the end, you'll be able to…

Why it matters