6.1.4. ALM for Data Used in AI Models and Agents
💡 First Principle: A solution does not contain data. It carries the agent, its topics, its actions, its connection references and its environment variables — and not a single Dataverse row. Every scenario in which "we promoted the solution and it still didn't work" turns out to be data that nobody designed a promotion path for.
This is its own exam objective, and it is the one most often skipped, because the artifacts are invisible in the solution explorer.
Five kinds of data, five different paths:
| Kind of data | Examples | How it moves between environments |
|---|---|---|
| Relational configuration data | Lookup tables, business-term glossaries, routing rules, prompt libraries held in Dataverse | Configuration Migration Tool — a schema file defines what to export, and import runs in multiple passes so dependent records resolve. Scriptable with the Microsoft.Xrm.Tooling.ConfigurationMigration PowerShell module |
| Non-relational configuration values | Endpoint URLs, feature toggles, tenant identifiers, thresholds | Environment variables, carried inside the solution with a per-environment value set at deployment |
| Grounding and knowledge sources | SharePoint sites, Dataverse tables, files, public websites | Not in the solution. Each environment points at its own source, and the sync/refresh configuration is set per environment |
| Training and evaluation data | Fine-tuning datasets, evaluation sets, embeddings | Versioned with the model in the Foundry registry (6.1.2), never in a Power Platform solution |
| Transactional / end-user data | Accounts, contacts, cases, orders | Never promoted. Production data stays in production; test environments get production-like data with PII removed |
⚠️ Exam Trap: The Configuration Migration Tool and environment variables are not alternatives — they cover different shapes of data. Relational configuration (rows with relationships between them) needs the Configuration Migration Tool; a handful of scalar settings belongs in environment variables. A scenario that describes promoting a table of routing rules is not solved by environment variables, however many of them you create.
⚠️ Exam Trap: Pipelines deploy solutions and connections, connection references and environment variables — which makes it tempting to conclude they deploy configuration generally. They do not deploy Dataverse data. Configuration data remains a separate, deliberately designed step.
The knowledge-source promotion failure. An agent promoted from dev to production keeps pointing at the dev SharePoint site, because the knowledge source reference travelled inside the agent definition rather than as an environment-specific setting. The agent works, answers confidently, and grounds every response in dev content. Nothing errors. Parameterise environment-specific sources, and make "verify each knowledge source resolves to this environment's data" an explicit gate in the promotion checklist.
Data lifecycle is coupled to solution lifecycle at exactly one dangerous point. Uninstalling a managed solution deletes data held in the custom tables and columns that solution introduced. A rollback that "just removes the solution" can therefore destroy production data that was never part of the deployment. Design the uninstall path, not only the install path.
Freshness is an ALM concern, not an operations one. A grounding index that stops refreshing produces no error and no alert — it produces confident answers about last quarter. Version the refresh configuration alongside the agent, and treat a change to refresh cadence as a change requiring promotion and testing.
Troubleshooting Scenario: A team promotes an agent to production. The solution imports cleanly, connection references are mapped, and smoke tests pass. Within a day, users report that the agent quotes discontinued products and unknown routing rules. Two separate data failures are in play: the knowledge source still resolves to the dev SharePoint site, and the routing rules table was never migrated, so production holds whatever rows existed before the project began. Neither is visible in the solution, and neither produces an error — which is precisely why data ALM has to be designed rather than assumed.
Reflection Question: An agent depends on a Dataverse table of 400 business-term definitions, a SharePoint knowledge source, an API endpoint that differs per environment, and a fine-tuned model. Assign each to its correct promotion mechanism, and identify which one would silently keep serving dev content if you forgot it.
