On 29 July 2026, Microsoft announced the general availability of Prompt Columns in Dataverse. You define a natural language prompt once on a table, and AI-generated classifications, summaries, and recommendations are computed and persisted as regular column values on every row. The insight stops being a read-time answer and becomes stored data: filterable in views, aggregable in Power BI, and triggerable in flows, with no code and no custom plumbing.
Prompt Columns Make AI Output a Persisted Dataverse Value, Not a Read-Time Answer
The mechanics are simple. On any Dataverse table you add a prompt column, write a natural language instruction that references other columns on the row, and Dataverse computes the result and stores it. Classify this ticket by urgency based on the description field. Summarize this feedback in one sentence. Recommend a next action based on status and history. The output lands in the column like any value a human would have typed.
I built this exact pattern by hand last year for an internal triage table. Flow triggers on row create, calls an AI Builder custom prompt, patches the result back into a text column, handles retries when the prompt action throttles, and logs failures somewhere nobody checks. It worked. It was also four moving parts to maintain for what is conceptually one thing: a computed field whose formula happens to be a prompt. Prompt Columns deletes that entire plumbing layer. Poof.
Storing the Insight Beats Regenerating It, With Two Caveats
Persistence is the whole story here, and I think it is the part most coverage will skip past. Nearly every AI-in-apps pattern generates insights on demand, at read time. That has two costs people underestimate. Every consumer pays inference cost for the same question, and every consumer can get a slightly different answer. A stored value flips both. The inference runs once, then a view can sort by it, a flow can trigger on it, a Power BI report can aggregate it across a million rows without a single additional model call. I wrote before about how the data path behind the model is often the real bottleneck, and this is the same principle from the other direction: put the AI output where the data already lives.
Two caveats before anyone switches this on across a production table. First, refresh semantics. If the description field changes after the classification was computed, when does the column recompute? A persisted AI value can go stale in a way a read-time answer never does, and you need to know the recompute triggers before you build a queue that sorts on it. Second, cost per row. One prompt execution per row sounds cheap until you enable it on a table with two million existing rows and think about backfill. Model the credit consumption before GA enthusiasm meets your capacity report. If you are already thinking about how to measure that spend against the work it produces, How to Measure Useful Work Per Dollar for Your Power Platform AI Agents is a useful starting point.
There is a third thing that is less caveat and more governance homework. AI-generated text now sits in a column that looks exactly like human-entered data. Nothing in a view distinguishes the two. If a downstream flow or a report treats that column as ground truth, you have quietly promoted a model output to a system of record. That is fine if it is a deliberate decision with a named owner. It is not fine as an accident.
Triage Queues and Classification Views Are the First Places This Pays Off
The obvious first wins are the boring ones, which is a compliment. Triage queues where incoming requests get an AI-assigned category and priority, and the queue view sorts by the AI column. Summary columns on long description fields so a service agent scans a readable sentence instead of opening every record. Sentiment on feedback rows, with a flow triggering on the negative ones and routing them to an owner. Every one of these was possible before with the flow-plus-prompt pattern. Now they are a column definition, which puts them in reach of makers who were never going to build the plumbing version.
The trade-off is worth naming. If you need per-user, per-context answers, or the insight depends on data outside the row, this is the wrong tool and read-time generation with an agent is still the right shape. That boundary also comes up when you are deciding where to store knowledge in the first place — SharePoint vs Dataverse as a Copilot Studio Knowledge Source covers how the two stores differ in ceiling, governance, and latency. In my experience, the honest split is: persist what is a property of the record, generate on demand what is a property of the question.
AI output stored as first-class, queryable data is where this whole space is heading, and a column type is exactly the right place for it to land.
Source: Prompt Columns in GA: Turning Business Apps Data into Persisted AI Insights (Microsoft Power Platform Blog).
Leave a Reply