Training a revised AI Builder document model and publishing it are separate steps. If a quick test shows new behavior but a flow still appears to use the old model, compare the published state, selected environment and actual action input before retraining again.
Use a non-production flow and approved samples. This guide concerns document processing models, not every AI Builder prediction feature. Publishing can affect existing consumers, so coordinate changes with the owner rather than treating it as a harmless refresh button.
Confirm the model and environment
Record the Power Platform environment and the selected model in the flow. Similar names across development and production can hide different resources. Inspect the model reference used by the action, not just the display name you remember from the training session.
Microsoft's custom document model guide describes checking the last trained and published model versions. It also explains that moving to a newer document-intelligence model generation involves editing, retraining and publishing. Those states should be inspected explicitly.
Separate a historical run from a new test
An old run records the behavior at its execution time. Publishing a model does not rewrite past run outputs. Start a new controlled execution after the approved change and compare it with a known sample.
Confirm which document was processed
Use a distinct harmless sample and inspect its source reference. A flow reading an older attachment or a cached test input can look like an old-model problem even when the selected model is current. Trace the actual bytes or source identity through the intake steps.
Review the publication decision
Before publishing, test the proposed model against representative held-out samples and compare required outputs. A newer version is not automatically better for every layout. Keep the currently accepted model behavior documented so regression can be recognized.
The official document processing flow reference describes selecting a trained and published model in the Process documents action. Check the current action and model availability in the intended environment. Older tutorials may use the earlier action name rather than the current label.
| Observation | What to verify |
|---|---|
| Quick test changed; flow did not | Published state and actual selected model |
| Only past runs show old fields | Run date versus publication date |
| Wrong output document | Source file reference and test input |
| New fields unavailable downstream | Current model schema and action mappings |
Recheck downstream mappings
A model change can add, rename or otherwise alter the fields expected by later actions. Inspect the outputs from a new run before updating destination mappings. Do not keep a similarly named dynamic token without checking which property it actually reads.
Test missing and changed fields
Include a sample where an optional value is absent. Ensure a downstream action does not fail simply because the revised model returns a different shape from the sample used during editing. Required-field validation should remain explicit.
Protect the accepted business process
Keep automated payments, external notifications and other material effects out of the initial model-version test. Verify the extracted proposal first, then let the owner approve the resulting workflow behavior. A successful model response is not an approval of the transaction it describes.
Document an accepted release
Record the environment, model label, trained and published versions available in the interface, publication date and sample outcomes. Do not retain raw confidential training documents in general project notes. Use authorized model-management and storage processes.
Our SharePoint metadata guide can help keep destination fields stable and distinguish unreviewed extraction from accepted values. A model update should not silently redefine the business meaning of a stored column.
If a fresh test still behaves unexpectedly, provide official support with the sanitized model reference, environment and timing evidence. Avoid repeatedly publishing or recreating resources without establishing which consumer uses them.
Notify the people maintaining dependent flows of the approved release. They should know which schema and sample outcome to compare if their next execution behaves differently, without needing access to private training material.
A model release needs the same explicit acceptance rules as ordinary extraction. The related verification guide is AI Builder Confidence vs Required-Field Validation.
Accept the change when the intended published model processes the intended sample in the intended environment, downstream fields map correctly and the owner's representative acceptance set passes. Keep the prior behavior distinguishable so future retraining can be reviewed as a controlled change rather than an unexplained replacement.
