Prompt actions and custom prompts

What it does

A prompt is a saved, reusable natural-language instruction with typed inputs, built in prompt builder and called from a flow with the Run a prompt action. The model generates text from the instruction plus whatever dynamic content you feed the inputs, and the output becomes a flow variable you use downstream.

Key facts

The action was renamed. Create text with GPT using a prompt became Run a prompt in May 2025 — older docs, blog posts and client screenshots still use the old name.
Prompts run on models sold through Azure AI Foundry and require Copilot Credits, Dataverse installed on the environment, and a region where the chosen model is available.
Prompt availability is per model, not per capability. The list lives in the Copilot Studio model availability by region table rather than the general AI Builder region page.
Credit consumption depends on input tokens including the system prompt, output tokens including reasoning tokens, and which model you picked.
Testing a prompt in prompt builder is free. Every other AI Builder capability is also free in preview, but prompts are the exception — a prompt running inside a flow consumes credits even when it's on a preview model.
The prebuilt AI functions — AISummarize, AIExtract, AIReply, AIClassify, AISentiment — are prompts under the covers and bill at the basic AI prompt rate.
You can attach input variables and knowledge data to give the model context at runtime, and share the saved prompt across flows, apps and agents.
If an admin turns the AI Builder preview toggle off, any prompt pinned to a preview model fails everywhere until someone edits it onto a GA model.

When to use / skip

Use prompts where the output is going to a human anyway — a drafted reply, a summary in a Teams message, a suggested categorisation someone confirms. Also good for turning messy text into a shape your flow can branch on, provided you validate the shape. Skip them anywhere the output drives an irreversible action without review. A model that's right 95% of the time is genuinely useful in a draft and genuinely dangerous in a payment run.

Configuration decisions

Which model each prompt is pinned to, and whether you'll accept a preview model in production.
Whether output goes straight through, through a lightweight condition check, or through an explicit approval.
Where prompts live — a shared solution so they're reusable and versioned, or inline in a flow where nobody else finds them.
How much context you feed in. Every extra token in the system prompt is paid for on every single run.
What the flow does when the model returns something unparseable, which it eventually will.

Gotchas

Output format drifts. If you're parsing the response, ask for a specific structure, validate it before use, and have a branch for when validation fails.
Long system prompts are a slow cost leak. They look free in testing because prompt builder tests don't bill.
The Start and wait for an approval of text action is purpose-built for this: it shows the generated text to a reviewer who can edit it before approving, and returns the accepted text. Most people build a plain approval and lose the editing step.
Prompts pinned to preview models are hostage to a tenant-level admin toggle you don't control.

Consultant notes

Position prompts as drafting and triage, not decision-making. It's an easier conversation up front than after an incident.
Get the human review pattern into the first prototype rather than bolting it on. Clients anchor hard on whatever the demo did.
Watch for prompt sprawl — a dozen near-identical prompts across a dozen flows, none of them in a solution. Put them in a solution from day one.
Cost is token-driven, so a prompt whose input is "the whole email thread" behaves very differently at month end than it did in testing.

Recheck when the model list or regional availability changes, or if the action gets renamed again