Using Prompts and AI Models in Apps and Flows
The four combinations that matter β prompts and AI models, consumed from canvas apps and from cloud flows β plus the async setting that silently breaks AI actions.
Two things to consume, two places to consume them
The last module built a prompt. AI hub also gives you AI models β trained capabilities such as reading a receipt or classifying text. Both can be called from a canvas app and from a cloud flow.
That gives four combinations, and the exam tests all four. Learn them as a grid rather than as a list.
| In a canvas app | In a cloud flow | |
|---|---|---|
| Prompt | Add it under Data, then call it as a Power Fx function | Add the Run a prompt action and pick the prompt |
| AI model | Call the model from the formula bar with Power Fx, or insert an AI Builder component where one exists for that model | Add the model's action, or use the predict action |
Think of AI hub as a cupboard. Prompts are instructions you wrote. AI models are tools β mostly ones Microsoft already built, like a receipt reader or a sentiment checker, plus ones you train yourself on your own data. Apps and flows both reach into the same cupboard; they just have different door handles.
Prompts in a cloud flow
The action is Run a prompt.
Wiring it up
- Add the Run a prompt action to the flow.
- In the Prompt field, choose an existing prompt from the dropdown β or select New custom prompt to author one inline without leaving the designer.
- Once a prompt is selected, its inputs appear below it. Fill each one with dynamic content from earlier steps in the flow.
- The action returns output as flow variables, which downstream actions consume like any other dynamic content.
A naming change worth knowing
This action used to be called Create text with GPT using a prompt. It was renamed to Run a prompt in May 2025. Older tutorials, blog posts, and screenshots still use the old name β if a question or a colleagueβs documentation mentions it, they mean the same action.
Prompts in a canvas app
In an app, a prompt behaves like a function you can call.
Wiring it up
- In Power Apps Studio, go to Data β + Add data and add your prompt. It joins the app the same way a table would.
- Call it from a formula using
.Predict()on the prompt name, passing the inputs as arguments. - The call returns a result you read a property from.
A buttonβs OnSelect might read:
Set(result, 'Task identifier'.Predict(TextInput1.Text))
and a labelβs Text property then shows result.text.
The important idea is that it is the same prompt. Improve the wording in prompt builder and both the app and the flow pick up the improvement β you do not maintain two copies.
AI models: prebuilt versus custom
Now the other half of the cupboard. AI models live under AI hub β AI models, and they come in two build types.
| Build type | What you do | Use when |
|---|---|---|
| Prebuilt | Nothing β the model is trained and ready to use immediately | The scenario is common across businesses: reading a receipt, detecting a language, scoring sentiment |
| Custom | Build it, train it on your data, then publish it | The data is unique to your business: your document layouts, your product images, your historical outcomes |
The decision rule is short enough to memorise: common problem β prebuilt; your data β custom.
Which models are custom
Most models are prebuilt. The ones that require you to build and train are the ones that depend on data only you have:
- Document processing β your document layouts
- Object detection β your products in images
- Prediction β your historical outcomes
- Category classification β available prebuilt and custom
- Entity extraction β available prebuilt and custom
That last pair is the trap. Category classification and entity extraction exist in both forms, so a question can legitimately go either way depending on whether the categories or entities are standard or specific to the business.
Picking the right model for a scenario
Scenario-to-model matching is exam bread and butter. The wording of the scenario gives it away.
| The scenario says | Model | Why |
|---|---|---|
| Automate expense reports from photos of receipts | Receipt processing | A receipt is a standard document shape across businesses |
| Pull key clauses and data points out of contracts | Contract processing | Purpose-built for contract documents |
| Extract fields from our own application form layout | Document processing | The layout is specific to the business, so the model must be trained on it |
| Work out whether feedback is positive or negative | Sentiment analysis | Sentiment is the literal capability |
| Sort feedback into topics | Category classification | Classification into categories |
| Pull product names and dates out of reviews | Entity extraction | Named things inside text |
| Work out what language a message is in | Language detection | Language identification |
| Turn support requests into our language | Text translation | Translation |
| Flag likely fraudulent transactions | Prediction | Learns an outcome from your historical structured data |
| Count our products on a warehouse shelf photo | Object detection | Trained on images of your specific products |
| Capture contact details from a business card | Business card reader | Purpose-built for business cards |
| Read text out of a photo and store it | Text recognition | Optical text extraction |
AI models in a cloud flow
Each model exposes actions in the flow designer β for example an action to analyse sentiment, extract entities, or read a receipt. There is also a general predict action that works with many model types.
Then there is the setting that catches people out.
The asynchronous pattern trap
For any AI Builder action in a cloud flow, leave the Asynchronous Pattern setting at its default of On. It lives in the actionβs settings, not on the action card itself.
Turning it off stops results from the AI model being returned properly. The flow may appear to succeed while producing nothing useful downstream β which is far harder to diagnose than an outright failure. If a scenario describes an AI Builder action that runs without error but returns no usable output, this setting is the first thing to check.
AI models in a canvas app
Two routes, and knowing which model supports which route is the testable part.
| Route | How | Covers |
|---|---|---|
| AI Builder component | Insert a ready-made control from the Insert tab in Power Apps Studio | Business card reader, receipt processor, text recogniser, form processor, object detector |
| Formula bar | Call the model from Power Fx, like any other function | Sentiment analysis, entity extraction, key phrase extraction, language detection, category classification |
Be careful about why the split exists, because this is a favourite trap. The route is model-specific β Microsoftβs wording is βtwo ways, depending on the model you will be using.β It is not determined by whether your scenario needs a user interface. A purpose-built component exists for only a short, fixed list of models; every other supported model is called through Power Fx, and you build any capture or display experience you need with ordinary controls. Power Fx supports all prebuilt and custom AI models, so βit needs a camera, therefore it must have a componentβ is exactly backwards.
Components and their build types
- Components backed by prebuilt models: business card reader (canvas and model-driven), receipt processor, text recogniser.
- Components backed by custom models: form processor, object detector β you must build and train the model before the component has anything to call.
Putting it together
Ravi wants drivers to photograph a damaged pallet, have the app describe what it sees, and have a flow decide whether to raise a claim.
How the pieces line up
- The app captures the photo with an ordinary image or camera control and calls the image model from the formula bar with
.Predict(). There is no purpose-built AI Builder component for image description β components exist only for a short, fixed list of models, and that is not one of them. - The flow uses a Run a prompt action to turn the extracted detail plus the shipment record into a plain-English claim summary.
- The prompt takes the damage detail as an input and uses the claims-policy table as knowledge.
- The summary goes to an approval, not straight to the customer β the human review step from the previous module.
- The AI Builder action in that flow keeps Asynchronous Pattern on.
Quick check
A maker adds an AI Builder action to a cloud flow. The flow runs successfully but downstream actions receive no output from the model. What should be checked first?
Which combination correctly describes calling a prompt from a canvas app?
Kite Freight wants to automatically identify which of its own branded containers appear in warehouse photos. Which model type fits?
What to carry forward
- Learn the grid: prompt or AI model Γ app or flow.
- Flow + prompt = the Run a prompt action, formerly Create text with GPT using a prompt.
- App + prompt = add under Data, then
.Predict(). - Flow + model = the modelβs action or the predict action β and leave Asynchronous Pattern on.
- App + model = the formula bar with Power Fx is the general-purpose route; an AI Builder component only where one exists for that specific model. The choice follows the model, not whether the scenario βneeds an interface.β
- The component list is short and worth knowing: business card reader, receipt processor and text recognizer use prebuilt models; form processor and object detector use custom ones. Anything else, reach for the formula bar.
- Prebuilt for problems every business has; custom for your documents, your images, your history.
- Category classification and entity extraction exist in both build types β read the scenario carefully.
Next you will step away from AI and into the declarative logic that runs whether or not anyone is watching: business rules and business process flows.