Prompt Columns are now generally available in Dataverse (announced July 29, 2026). They let you persist AI generated summaries, classifications and extractions as text directly on your tables. The gain is obvious: a durable value the rest of your model can query. The risk is also obvious: uncontrolled triggers, noisy writes, and an open credit tab.

This guide shows how to implement Prompt Columns end to end with predictable triggers, idempotency, audit and rollback, and environment aware cost controls. As of August 2026, there is no on demand recalculation or built in auditing, and spend is token based. The patterns below keep production reliable and affordable.

Contents

What Prompt Columns actually do in Dataverse

As of August 2026, a Prompt Column is a specialized text column that runs a configured prompt and writes the result back to the same row. Execution is automatic when a record is created or when one or more referenced input columns change. If none of the referenced inputs change, the prompt does not run and no credits are consumed. You can further constrain execution with filter conditions in the column designer.

Key characteristics:

  • Execution is asynchronous: the prompt run is decoupled from the transaction that changed the row. The system surfaces state via Status and Details system columns associated to the Prompt Column.
  • Triggers are bounded by inputs: only changes to the columns you select as inputs can invoke the run. Formula columns, file or image columns, and other Prompt Columns are not valid inputs.
  • Scope limits: up to five Prompt Columns per table, and they store text outputs. At the metadata level they are a specialized column type and sit on StringAttributeMetadata.
  • Governance controls: you can disable execution for a specific Prompt Column without deleting it by clearing the Allow prompt column execution setting. Both tenant features and this per column switch must be enabled for runs to happen.

Important: Prompt Columns are not audited. Changes to their values will not appear in Dataverse audit history. If lineage matters, implement your own audit and versioning.

Setup and prerequisites for a safe first column

Before building, confirm these prerequisites and choices.

  • Enable the relevant tenant and environment features for AI in the Power Platform admin center. Prompt Columns require these features to run.
  • Decide the credit source. In Power Apps and Power Automate, AI Builder features can consume AI Builder credits or fall back to Copilot Credits if AI Builder credits are unavailable. Copilot Studio scenarios always consume Copilot Credits. Seeded AI Builder credits included with some licenses are scheduled to be removed in November 2026.
  • Allocate Copilot Credits to the target environment if that is the source you expect to use. Credits are pooled tenant wide and must be assigned per environment.
  • Choose the model tier for your scenario. Cost depends on tokens and model version. Start with the least expensive tier that yields acceptable quality.
  • Decide inputs and a concise output. Shorter inputs and constrained outputs reduce tokens and increase reliability.

Create the first Prompt Column:

  1. In your Solution in the maker portal, open the table and choose Add column. Select Prompt column.
  2. Define the prompt text and select the input columns that should trigger execution. Avoid formula, file, image and other Prompt Columns as inputs.
  3. Add an execution filter if only a subset of records should run. Example: only when priority equals High.
  4. Save and publish. Confirm that Allow prompt column execution is enabled.

Controlled triggers and idempotency you can prove

There are two layers to control when prompts run: the column configuration itself and upstream app or flow triggers.

Column level:

  • Reference only the columns that should cause recalculation. If the update payload does not include these inputs, the prompt does not run.
  • Use the column filter to gate runs to the minimum set of records that actually need the AI result.

Flow level:

  • Use the Dataverse trigger When a row is added, modified or deleted with Change type set to Update and Select columns set only to the scalar inputs that matter. Lookup columns are not supported in Select columns. Do not include the Prompt Column Status field in Select columns to avoid self triggering on the asynchronous status updates.
  • Add a Get row (Dataverse) action immediately after the trigger to read the current record. Use the Row ID from the trigger body.
  • Add an early Condition action to short circuit when a previous successful run already exists and the inputs have not changed. Do not hard code status codes. Load the Completed code from your environment (for example, via an environment variable or metadata query) and compare to that value using the output of Get row.

Example configuration:

Select columns: description,rootcause,priority
Important: do not include the Prompt Column Status field in Select columns.
Get row: Row ID = triggerOutputs()?['body/<yourprimarykeylogicalname>']
Early Condition expression (inside the flow):
@equals(outputs('Get_row')?['body/crm_caseSummary_PromptColumnStatus'], variables('CompletedCode'))

Before using the expression, set a variable CompletedCode to the value of the Completed option in your environment's Prompt Column Status choice. Replace crm_caseSummary_PromptColumnStatus and <yourprimarykeylogicalname> with your logical names.

In the flow body, handle the asynchronous nature:

  • Poll the Prompt Column Status (from Get row) until it transitions out of in progress, or react to a follow on Dataverse event that signals the status change. Use the same environment specific Completed code value you loaded earlier.
  • Update dependent fields only after a successful run. Avoid chaining logic that assumes immediate availability.

Idempotency pattern:

  • Keep a shadow text column that stores the last set of concatenated inputs used for the prompt. Before acting on a new result, compare current inputs to the shadow. If identical, skip downstream updates even if the Prompt Column re executed for operational reasons. This avoids writing duplicates.

Cost model in practice: tokens, models, estimation

Charges are driven by tokens and the chosen model version. As of August 2026:

  • Inputs include your prompt, your data, and a system metaprompt that is approximately 1,200 tokens.
  • Outputs include the model completion and may include reasoning tokens depending on the model.
  • Model tier affects the rate card for both inputs and outputs.

A simple worksheet to estimate per run cost:

  1. Count input tokens: approximate for your data plus 1,200 for the system metaprompt.
  2. Set an output token budget that covers the worst acceptable case.
  3. Multiply by the rate for the selected model tier.
  4. Add a safety factor for retries and variance.

Where to measure after the fact:

  • In flows that call saved prompts, read input and output token counts from the action outputs.
  • In platform executed Prompt Columns, use the AI Event table fields to see credit consumption per execution.

Cost driver controls:

Cost driver What it includes How to control it Where to measure
Input tokens Data columns, prompt text, system metaprompt (~1,200) Trim inputs, summarize upstream, avoid long histories Action outputs in flows, AI Event records
Output tokens Completion and reasoning tokens Constrain output with explicit format and max length Action outputs in flows, AI Event records
Model version Tier specific rates Start with the least expensive model tier that meets quality Licensing pages and rate cards
Execution frequency How often inputs change Use Select columns, execution filters, and batching AI Event volume over time

Important: Testing in the prompt builder does not consume credits. Executions in apps, flows and agents do.

Instrumentation and alerting: AI Event and activity exports

Two places expose telemetry as of August 2026:

  • The AI Builder activity page: model and prompt activity by environment.
  • The AI Event table (msdyn_AIEvent): logs prompt runs, including fields such as msdyn_processingdate, msdyn_creditconsumed and msdyn_output.

Query recent executions via the Web API to build your own dashboard or alerts:

GET /api/data/v9.2/msdyn_aievents
  ?$select=msdyn_processingdate,msdyn_creditconsumed,msdyn_output,msdyn_aiconfigurationid
  &$filter=msdyn_processingdate ge 2026-08-01T00:00:00Z

Pattern for a weekly spend alert flow:

  1. Recurrence trigger weekly.
  2. List rows from msdyn_AIEvent with a date filter and the target environment scope.
  3. Sum msdyn_creditconsumed grouped by Prompt Column configuration.
  4. Compare to thresholds for the environment and send notifications or create a Dataverse incident record.

To correlate events to business rows at scale, persist the table name and row ID in your AI configuration naming or in a companion setting so you can group AI Event rows meaningfully during analysis.

Copilot Credit allocation and monitoring:

  • Credits are pooled at the tenant level and must be assigned to environments.
  • As of August 2026, per agent monthly limits in Copilot Studio are in public preview (rollout in progress) with notifications and hard stops. Verify availability in your tenant and use it for Copilot Studio agents. Prompt Columns themselves do not have per column caps, so use environment allocation and custom alerting to enforce a budget.

Auditability and rollback: shadow and versioning pattern

Prompt Column values are not audited. If you must preserve lineage and enable revert, add explicit audit and rollback components.

Design:

  • A shadow text column on the same table to store the previous prompt output.
  • A versioning table with a many to one relationship to the business table that captures each write.

Suggested versioning record shape:

{
  "name": "Prompt Output Version",
  "columns": [
    { "name": "parentid", "type": "lookup", "target": "your_table" },
    { "name": "promptcolumnlogicalname", "type": "text" },
    { "name": "outputtext", "type": "multiline-text" },
    { "name": "inputsignature", "type": "text" },
    { "name": "processingdate", "type": "datetime" },
    { "name": "credits", "type": "number" },
    { "name": "status", "type": "choice" },
    { "name": "details", "type": "multiline-text" }
  ]
}

Flow pattern to snapshot and enable rollback:

  1. Trigger when the Prompt Column Status changes to the environment specific Completed value.
  2. Compare the concatenated inputs to the stored inputsignature. If different, create a versioning record with outputtext, inputs, processingdate, credits and details.
  3. Copy the current Prompt Column value to the shadow column.
  4. For rollback, provide an on demand Power App or admin flow that writes the selected version back into the Prompt Column and updates the shadow accordingly. Disable Allow prompt column execution during rollback to avoid re execution, then re enable when done.

Retention:

  • Apply appropriate retention to versioning rows and to AI Event. The AI Event table can store text inputs and outputs, so align with data handling policies.

Backfills without bill shock

Prompt Columns do not support on demand recalculation. Existing rows are not processed unless a referenced input is updated. To safely recompute at scale after a prompt change or schema change:

Batch nudge pattern:

  1. Add a benign scalar column to the table, for example backfillmarker. Include it as an input to the Prompt Column.
  2. Use a scheduled flow to update backfillmarker in small, controlled batches sized to your environment’s capacity and budget. Monitor AI Event and adjust batch size based on observed run times and spend.
  3. After each batch, monitor the Prompt Column Status and Details until the batch completes. Record failures in an operations table.
  4. Pause or stop if spend exceeds the weekly allowance based on AI Event credit totals.

Important: Every re execution consumes credits. Plan batch sizes and schedules around your environment allocation and thresholds.

ALM: moving Prompt Columns across environments

Prompt Columns are solution components. Treat them like any other table column in ALM.

  • Build only in development environments where unmanaged customizations are allowed. If Block unmanaged customizations is enabled in test or production, creating or editing Prompt Columns there will fail.
  • Ship changes as managed solutions through pipelines. Use segmented solutions that include only the updated table and columns to minimize risk.
  • Coordinate feature flags with releases. If you need to pause execution during a deployment or hotfix, clear Allow prompt column execution on the column, deploy, validate, then re enable.
  • Backfills should run only after all environments have the same version of the prompt and inputs to avoid divergent outputs.

Moving references safely:

  • Input column logical names should be stable across environments. Avoid renames that could silently change behavior.
  • Because Prompt Columns store text outputs, down level consumers rarely need schema changes. Keep your output format stable to avoid breaking downstream logic.

Failure modes and mitigations

Prompt Columns share the underlying prompt runtime family used elsewhere in the platform. Practical failure modes as of August 2026 and mitigations:

  • Timeouts or throttling: reduce input size, constrain outputs, and use filters to run only when needed. Add retry logic in the reaction flow with exponential backoff.
  • Token window exceeded: summarize long texts upstream, split large inputs, and set strict output limits.
  • Inconsistent response times: handle the asynchronous nature by polling or reacting to status changes rather than expecting immediate values.
  • Invalid inputs: validate required inputs before updates land. If an input is missing, skip updates that would trigger a run.

Operational guardrails:

  • Disable execution during incident response to stop new runs. Re enable after confirming stability.
  • Keep a dashboard of failure counts by Prompt Column using AI Event records (for example, msdyn_processingdate and msdyn_creditconsumed) and the Prompt Column’s own Status and Details system columns. Investigate sustained changes in failure rate.

What to watch carefully

  • Maturity and rollout: asynchronous execution behavior and regional rollout can differ. Verify behavior in your environments before wide release.
  • Auditing gap: there is no built in audit for Prompt Columns. If audit and lineage are required, the shadow plus versioning pattern is mandatory.
  • Spend visibility: Prompt Columns do not have per column spend caps. Environment assignment of Copilot Credits and custom alerts are the only hard controls.
  • Backfill strategy: because there is no on demand recompute, controlled nudge updates are the path to re execution. Size batches to your credit allocation and SLA.
  • Rate card changes: model availability and pricing can change. Re validate cost assumptions regularly.
  • Data handling: AI Event can store text inputs and outputs. Align with security and retention policies before turning on broad logging.

My take

Prompt Columns are ready for production if they are treated as a write behind system with budgets. The winning design keeps triggers narrow, outputs short, and telemetry first class. Put a versioning table in from day one, disable execution during risky changes, and alert on spend from the AI Event table. Start with the least expensive model tier that meets quality, and only widen inputs or outputs when there is a proven benefit. This keeps data reliable and costs predictable while the platform evolves.

Sources

Categorizado en:

Dataverse,

Etiquetado en:

, , , , ,