… 5 unchanged lines …
  - 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.
+ - Generation fires on record creation and on update of a column named in the prompt definition. By default existing records aren't processed. A **bulk backfill** option is now documented (see below), and Microsoft says it's still rolling out, so it may not be in your region yet.
+ - **Bulk backfill:** tick **Also generate values for Existing records in bulk** on the column panel, review the record count and the estimated credit consumption, save, then choose **Run prompt**. It runs as an asynchronous job in **System jobs**, and Status and Details update per record.
+ - Two environment settings in Power Platform admin center (Settings > Features) govern it: **Allow bulk processing of existing records** (off by default) and **Require review before processing imported prompt columns** (on by default, so an imported job pauses until someone starts it).
+ - Backfill jobs expire after seven days and are cancelled whatever their state. Successful jobs stay visible in System jobs for 30 days, failed or cancelled ones for 60.
  - 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.
    … 3 unchanged lines …
  ## 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.
+ Bad fit: anything the business will treat as a fact. There's no audit trail, backfill is new and limited, there's no clean 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.
+ - How historical rows get treated: bulk backfill where it's rolled out (switch on the environment setting only once capacity is confirmed), or a one-off touch of an input column elsewhere, which 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.
+ - Editing a prompt still doesn't reprocess existing rows on its own. Reprocessing means the bulk backfill option, where it's available, and that bills for every row it touches, so filter first and test a handful of records to see what your data costs.
+ - A prompt column job imported in a solution waits for review by default and cancels itself after seven days. Deployments that import on a Friday and nobody starts the job come back to nothing generated.
  - 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.
    … 7 unchanged lines …
  
  ---
  
- *Recheck the asynchronous rollout and the auditing answer — both were still moving in the May 2026 docs*
+ *Recheck the asynchronous rollout, the bulk backfill rollout and the auditing answer — all were still moving in the docs. Refreshed 2026-10-24 for bulk backfill, its two environment settings and job expiry.*