Refresh Data

refresh triggers processing at model, table, or partition scope and can also provide refresh observability:

• live DMV status for Desktop or Service XMLA connections,
• Desktop-local refresh plans and MCP-initiated history,
• Power BI Service refresh history,
• Power BI Service execution details and failure diagnosis,
• reliability and stale/SLA checks over recent Service history.

Use it when:

• you changed partitions or schema and want to validate on fresh data,
• you need to confirm that a processing request was submitted,
• you want to run a calculate-only processing pass (when appropriate).
• you need to understand why a Power BI Service semantic model refresh failed.

You typically won’t call the tool directly-tell the LLM what you want refreshed and why, and it will use refresh safely.

What to ask the LLM (quick prompts)

Scopes (what you can refresh)

You can refresh at:

• Model: processes all tables except tables marked exclude_from_model_refresh by default.
• Table: processes all partitions of a table.
• Partition: processes a specific partition in a table.

If you’re not sure what partitions exist:

Refresh types (what “Full / DataOnly / Calculate” mean)

The tool supports three processing types:

• Full: standard processing (data + calculations as needed).
• DataOnly: process data without forcing a full calculation pass.
• Calculate: force calculation processing.

Important nuances:

• Unknown refresh_type values are rejected. Valid values are Full, DataOnly, and Calculate.
• Some calculated tables/partitions don’t support Full/DataOnly processing in the engine. In those cases, the server reports an override to Calculate before execution.

If you care about exactly what will happen:

Planning before execution

Use operation="plan" to see the exact Desktop-local refresh plan without mutating the model:

{ "operation": "plan", "scope": "Model", "refresh_type": "Full" }

Plans include:

• target scope and affected tables/partitions,
• requested versus actual refresh type,
• calculated table/partition overrides,
• skipped tables marked exclude_from_model_refresh,
• warnings for broad model refreshes or large partition sets.

Model refresh skips tables marked exclude_from_model_refresh by default. Set include_excluded=true only when you explicitly want to refresh those tables too.

Status-only checks (best-effort)

You can ask for status without triggering a refresh:

What status means:

• The server inspects engine DMV state and returns a best-effort signal like “is a refresh-like command currently running?”.
• Results include best_effort=true, status_source="discover_commands_dmv", confidence, and limitations.
• It does not guarantee a full “job history”, request/job ID, progress percentage, or reliable in-progress detection, and it may miss work depending on host/engine behavior.
• Legacy payloads with status_only=true are treated as operation="status".

Prompt:

Refresh history and diagnostics

For Desktop connections, operation="history" returns local history for refreshes initiated by SemanticOps MCP. It includes explicit refresh executions and automatic post-write refreshes initiated by manage_schema, with trigger_source distinguishing entries such as refresh_tool, schema_create_table_process, schema_update_partition_process, and schema_calculated_column_materialization. It is not Power BI Desktop's full refresh history and cannot include refreshes started outside SemanticOps MCP.

For Power BI Service connections, refresh supports read-only Service diagnostics:

• operation="history": recent refreshes with request ID, status, timing, attempts, and sanitized service exception summaries.
• operation="details": execution details for a supplied request_id, including messages, attempts, objects, and metrics when the REST API returns them.
• operation="diagnose": classify a supplied request_id or latest failed refresh as gateway, credentials, source timeout, mashup/query, permissions, capacity/memory, disabled, cancelled, throttled, or unknown.
• operation="reliability": success rate, consecutive failures, last successful refresh age, duration percentiles, stale flags, and recommended actions.

Examples:

{ "operation": "history", "limit": 20 }

{ "operation": "details", "request_id": "9399bb89-25d1-44f8-8576-136d7e9014b1" }

{ "operation": "reliability", "limit": 20, "max_age_minutes": 120, "max_duration_minutes": 30 }

Notes:

• These operations require a selected Power BI Service model and suitable REST permissions.
• Desktop connections use local MCP-initiated history for operation="history" and return clear unsupported results for Service-only details, diagnose, and reliability.
• Service exception text is redacted before it is returned.

Locked-down environments (mode behavior)

If refresh is blocked, ask:

Common workflows

1) Refresh after partition work

2) Partition refresh (incremental patterns)

3) Calculate-only pass (targeted)

4) “Don’t surprise me” safety pattern

Troubleshooting

See also

• Change safely
• Query and validate
• Tools index