What it does

A prompt column is a Dataverse data type that runs a natural-language prompt against other columns on the same row and stores the generated text in the column. The result is persisted data — apps, views, flows and reports read it like any other column. Alongside that sit the AI functions (AISummarize, AIExtract, AIReply, AIClassify, AISentiment, AITranslate), which are prebuilt prompts you call from Power Fx instead of authoring your own.

Key facts

• Up to five prompt columns per table.
• Prompt columns follow the AI Builder prompts licensing model and consume Copilot credits. Consumption depends on input tokens including the system prompt, output tokens including reasoning tokens, and the model used — so it varies per row, not per execution.
• Execution is asynchronous. Microsoft was still rolling this out at the May 2026 documentation update; columns created on earlier versions keep their old behaviour until the environment upgrades, and prompt definitions are updated as part of that upgrade.
• Every prompt column automatically gets two companion columns, (columnName)_PromptColumnStatus and (columnName)_PromptColumnDetails. Status runs 0 NotStarted, 1 InProgress, 2 Completed, 3 Failed, with the failure reason in Details.
• Generation fires on record creation and on update of a column named in the prompt definition. Existing records aren't backfilled, and there's no on-demand execution — changing the prompt doesn't recalculate anything until a subsequent update touches an input column.
• Input columns can't be formula columns, file columns, image columns or another prompt column. Select one of those and its value is silently ignored.
• Prompt columns aren't audited.
• Filter conditions on a prompt column let you run generation only for rows that meet a condition, which is the main lever you have on credit consumption.
• The Block unmanaged customizations environment setting must be off to create or edit a prompt column — you'll get an error about the msdyn_AIConfiguration component otherwise.
• Both the tenant-level AI Prompts feature setting and the column-level Allow prompt column execution checkbox have to be on for anything to run.

When to use / skip

Good fit: enriching rows with derived text that a human would otherwise write — summarising a long case description, classifying inbound feedback, extracting a handful of fields from free text. It's cheap to build, it lands in the data model, and reporting picks it up without extra work.

Bad fit: anything the business will treat as a fact. There's no audit trail, no backfill, no re-run, and generation happens after the write rather than as part of it. If a decision, an approval or an external communication depends on the value, you want a plug-in or a flow calling a prompt explicitly, where you control retries, logging and the point in the transaction. Treat the prompt column as an enrichment, not a calculation.

Configuration decisions

• Which columns are the inputs, and therefore which updates trigger regeneration. Choosing a chatty column as an input is how credit consumption gets away from you.
• Whether a filter condition should gate execution, and what the condition is.
• Whether the Status and Details columns go on a form or a view. If nobody surfaces them, nobody notices failures.
• Whether the requirement genuinely needs persistence, or whether an AI function called at the point of use is a better fit.
• How historical rows get treated, given there's no backfill — usually a one-off touch of an input column, which then bills for every row.

Gotchas

• No backfill and no on-demand run means editing a prompt doesn't fix existing rows. People assume they can tune the prompt and reprocess; they can't.
• Prompt columns aren't audited. Anyone who has assumed Dataverse auditing covers everything will find a gap during the compliance review, not before it.
• A failure caused by the user lacking permission on one of the input columns shows up as a generation failure, not a security error. Column-level security on an input column produces confusing intermittent failures.
• Because generation is asynchronous, a flow or plug-in reading the prompt column immediately after create gets an empty value. Race conditions here are common and look like flaky data.
• Blocking unmanaged customizations is a governance best practice that makes prompt columns uneditable. Those two decisions collide and someone has to choose.

Consultant notes

• Get the credit conversation in before the build, not after the pilot. Consumption scales with row volume and token size and it's very easy to attach a prompt column to a table that receives ten thousand rows a day.
• Position prompt columns as a maker capability with a governance cost. They create AI configuration components that ship in solutions and need the same ALM discipline as anything else.
• The lack of auditing is the point to raise with regulated clients. Say it plainly rather than letting it surface in a security review.
• Where the requirement is "summarise this for the user right now", an AI function in the app is usually simpler and cheaper than a stored column. Ask what's actually reading the value.

---

Recheck the asynchronous rollout and the auditing answer — both were still moving in the May 2026 docs