14.3 Consuming AI Models in Apps and Cloud Flows

AI Builder models live under AI hub > AI models in make.powerapps.com or make.powerautomate.com (left navigation … More > AI hub). The first exam distinction is prebuilt versus custom: prebuilt models are trained by Microsoft and ready to use immediately; custom models are trained on your data and are useless until you publish them.

The prebuilt catalog

Exam trap: object detection and prediction exist only as custom models — there is no prebuilt object detection model. Similarly, document processing (sometimes called form processing) is always custom because the fields are specific to your forms.

Custom models: train, publish, share

The custom model lifecycle is consistent across types:

1. Collect — for document processing, upload sample documents; 5 documents is the minimum to train, but use more for accuracy
2. Tag — draw boxes around the fields, tables, and checkboxes the model should extract (or label categories/objects for classification and object detection)
3. Train — AI Builder builds the model; training time varies with data volume
4. Test and publish — review quick-test results, then publish; only published models can be added to apps and flows
5. Share — grant users access to the model so their apps and flows can execute it; an unpublished or unshared model fails for everyone except its owner

Prediction models answer two-outcome business questions from historical Dataverse data (for example, will this opportunity close?) and require historical rows that already contain the outcome so the model can learn the pattern. Custom category classification learns your own tagging taxonomy from labeled examples. Custom object detection counts and locates your products in photos — the classic inventory-taking scenario — and training needs at least 15 images per object name you want to detect. Sharing deserves one more note: a maker can share a published model with individual users so those users' apps and flows can execute it, which is the standard fix when a colleague's flow fails with an access error against your model.

Consuming models in canvas apps

Two patterns exist in Power Apps Studio:

• AI Builder components on the Insert tab — drag-and-drop controls with a built-in camera/scan experience. Prebuilt-based: business card reader, receipt processor, text recognizer. Custom-based: form processor (binds to your document processing model) and object detector (binds to your object detection model). Results surface through control properties such as TextRecognizer1.Results or the form processor's Fields and Tables.
• Power Fx formulas — text-oriented models are callable from the formula bar: sentiment analysis, entity extraction, key phrase extraction, language detection, and category classification (prebuilt and custom). Power Fx support extends to all prebuilt and custom models, and custom models can also be called through .Predict once added from Data > + Add data.

Scenario: an expense app pairs the receipt processor component with a form — the control returns merchant, date, and total, and the app writes them straight to a Dataverse expense row.

Consuming models in cloud flows

Each model maps to a dedicated action on the AI Builder connector in Power Automate — Extract information from invoices, Recognize text in an image or a PDF document, Analyze positive or negative sentiment in text, Read business card information, and the custom-model action Extract information from documents (your published document processing model appears in its model dropdown). A standard pattern: When a file is created in SharePoint > run the invoice action > create a row in the Invoices table.

Confidence scores and error handling

Every extracted field and prediction carries a confidence score between 0 and 1. Production designs never trust it blindly:

• Add a condition comparing the score to a threshold (for example, 0.80); below the threshold, route the item to a human review step such as an approval instead of writing it to Dataverse
• Wrap the AI Builder action in a scope and add a run-after branch for failed/timed out outcomes
• Remember that a flow action referencing an unpublished or deleted custom model fails at run time — republish after retraining

Exam trap: prebuilt models require no training and no publishing — if a scenario says "start extracting receipts today with zero setup," the answer is a prebuilt model, not a custom document processing project.