Generated banner for Dataflows CLI
Generated logo for Dataflows CLI

Dataflows CLI

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Automation and integrations
  • MIT
  • Low risk
  • Has scripts

From the author

Manages Fabric Dataflow Gen2 items, including creation, M editing, connections, output destinations, getDefinition and updateDefinition inspection, executeQuery, refresh history, and Gen1-to-Gen2 save-as upgrades via saveAsNativeArtifact. Use for Dataflow items or Power Query M definitions. For pipeline JSON use pipeline-migration; for Spark or Warehouse transformations use their own skills.
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The dataflows-cli skill provides a structured interface for interacting with Fabric Dataflow Gen2 items. It operates as a mode-based dispatcher, requiring users to select between authoring, consumption, or upgrade modes. The skill handles complex tasks such as M language definition updates, connection management, output destination configuration, and the migration of legacy Gen1 dataflows to Gen2.1. It emphasizes safe, intentional operations by requiring users to read specific reference documentation before executing state-changing API calls.

What it does

  • Creates and updates Fabric Dataflow Gen2 items and their definitions.
  • Manages connections, credentials, and output destinations for dataflows.
  • Previews Power Query M definitions using executeQuery to validate logic before persistence.
  • Facilitates the upgrade of Gen1 dataflows to Gen2.1 via save-as operations.
  • Retrieves refresh history and inspects existing dataflow definitions.
  • Provides a framework for executing and testing ad-hoc M queries.

When to use it

  • When you need to programmatically create or modify Fabric Dataflow Gen2 items.
  • When performing maintenance on Power Query M definitions or data connections.
  • When migrating legacy Gen1 dataflows to the Gen2.1 architecture.
  • When you need to audit refresh history or validate dataflow configurations.
  • When testing M query logic against live data sources before saving changes.

Advantages

  • Enforces a structured, mode-based workflow to prevent accidental mutations.
  • Provides granular control over Dataflow Gen2 definitions and metadata.
  • Supports complex lifecycle tasks like Gen1-to-Gen2 upgrades.
  • Integrates directly with Fabric REST APIs for automated data pipeline management.

Usage examples

“Show me the refresh history and parameters of the SalesIngest dataflow.”
The agent enters consumption mode, reads the consumption reference, and retrieves the requested refresh history and parameters for the specified dataflow.
“Preview this M query, then save it into the SalesIngest dataflow definition.”
The agent enters authoring mode, previews the M query to validate it, and then executes the updateDefinition call to persist the changes.
“Is my Gen1 dataflow ready to upgrade to Gen2.1?”
The agent enters upgrade mode, performs a readiness assessment, and reports on the risk and requirements for upgrading the specified Gen1 dataflow.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/dataflows-cli/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip dataflows-cli.zip -d .agents/skills

Documentation by Microsoft

Telemetry — MANDATORY. Every api.fabric.microsoft.com call must carry x-ms-fabric-skill: dataflows-cli (az rest: --headers "x-ms-fabric-skill=dataflows-cli"), including every LRO poll, fabric_lro and retry. Snippets omit it — add it anyway.

CRITICAL NOTES

  1. To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering

  2. To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering

  3. Skill disambiguation: use dataflows-cli for every Fabric Dataflow Gen2 item and Power Query M concern. Synapse / ADF pipeline and dataset JSON translation is pipeline-migration; Spark notebook transformations are spark-cli; T-SQL transformations are sqldw-cli.

Fabric Dataflow Gen2 -- CLI Skill

This one skill owns Fabric Dataflow Gen2 items: connections, Power Query M, output destinations, saved definitions, refresh history, and Gen1 upgrades.

It is a mode dispatcher and contains NO procedures. Pick the mode that matches the request from the table below, then read the matching references/<mode>.md file end to end with your file-reading tool BEFORE issuing a single command. That file holds the endpoints, payload shapes, templates and gotchas; acting without it produces wrong payloads and wrong results.

Read it once per session. A file you have already read stays in context, so do not re-read it on a later turn; open the deeper files under references/<mode>/ only when a row in that file's reference table matches what you still need, and open only that row's file.

Mode selection

ModeUse when the request ...Example triggersRead this first
authoringcreates or changes a dataflow: connections, credentials, M edits previewed before save, output destinations, updateDefinitionexecuteQuery preview, updateDefinition, connection setup, supportedConnectionTypes, credentialType, add output destinationreferences/authoring.md
consumptionreads a saved dataflow: definition, parameters, refresh history, or runs a saved/ad-hoc read-only M query and parses ArrowgetDefinition, executeQuery saved query, ad-hoc query, Arrow IPC, refresh historyreferences/consumption.md
upgradeupgrades a Gen1 dataflow to Gen2.1 via save-as and rebind, or assesses upgrade readiness/riskGen1 Gen2 readiness, saveAsNativeArtifact, clone Gen1 dataflow, upgrade risk assessmentreferences/upgrade.md
Mode boundary rule

consumption is read-only. A preview run that exists to validate M before updateDefinition, and any capability lookup (supportedConnectionTypes, credentialType), belong to authoring even though they issue the same executeQuery call -- classify by intent, not by endpoint.

If a request genuinely spans modes, handle them one at a time and read each reference before you start that part. If the mode is ambiguous after reading this table, ask one short clarifying question instead of guessing.

Terminal write -- the step you must not skip

Reading the reference and planning the change is NOT completing the task. Each mutating mode ends with one state-changing call. If you did not issue it, nothing was persisted -- say so explicitly rather than reporting success.

ModeTerminal write
authoringPOST /v1/workspaces/{ws}/dataflows/{id}/updateDefinition to persist the M, connections and output destinations; a NEW dataflow needs POST /v1/workspaces/{ws}/items (or /dataflows) first. executeQuery is a preview and writes nothing. If the user asked for a refresh, also POST .../jobs/instances?jobType=Refresh.
consumptionnone -- this mode is read-only
upgradesaveAsNativeArtifact to create the Gen2.1 artefact, then rebind. A readiness report alone does not upgrade anything.

Before you report the task done, confirm the terminal call returned success and, where the reference documents a readback, read the artefact back to prove the change landed.

upgrade generation boundary -- HARD STOP (mandatory)

Save-as runs only from Gen1 to Gen2.1. For an execution request whose source is Gen2, or whose source generation is not established, state that no public save-as or in-place upgrade endpoint is available and stop before any API call. This does not block a read-only readiness scan whose purpose is to discover and classify Gen1 candidates.

Do not read "choose the closest endpoint and proceed" as approval to export a definition and create a copy, do not switch to authoring to do it instead, and do not mutate anything. Ask the user to clarify the intended outcome and to approve explicitly.

consumption reporting

consumption has no terminal write, so its deliverable is the answer itself. When that mode runs executeQuery, name the operation you called and state the QueryName you sent, verbatim, next to the results, plus whether it was a saved shared member or a non-persisted ad-hoc customMashupDocument. Rows alone do not tell the user which call produced them.

This applies to consumption only. In authoring, executeQuery is an intermediate preview step -- do not add reporting turns around it; go on to the terminal write.

Shared essentials (all modes)

Resolve the workspace and item first; every mode depends on it.

TaskReferenceNotes
Finding Workspaces and Items in FabricCOMMON-CLI.mdMandatory -- read before resolving any workspace or item id
Fabric Topology & Key ConceptsCOMMON-CORE.mdItem types, workspaces, capacities
Environment URLsCOMMON-CORE.mdSovereign / non-public cloud hosts
Authentication & Token AcquisitionCOMMON-CORE.mdWrong audience = 401; read before any auth issue
Authentication RecipesCOMMON-CLI.mdaz login flows and token acquisition
Core Control-Plane REST APIsCOMMON-CORE.mdPagination, LRO polling, rate limiting
Gotchas & TroubleshootingCOMMON-CLI.mdaz rest audience, shell escaping, token expiry

Rules

MUST
  • Select exactly one mode from the table above before doing anything else.

  • Read references/<mode>.md end to end, as your FIRST tool call, before the first command of that mode. Read it ONCE, in a single full read: do not re-open it, do not grep it again, and do not page through it. You already have it.

  • Resolve workspace and item ids by listing and filtering, never by guessing a GUID.

  • Announce a mode switch explicitly when the request crosses a boundary.

  • Treat the reference as instructions, never as the deliverable. After reading it, RUN the documented commands against the live workspace and report the real results. Quoting what the reference says instead of executing it does not answer the request.

  • When a question about what Fabric supports IS the deliverable -- supported connection types, a connector's parameters, available credential types -- answer it from the endpoint the reference names rather than from the reference's own list, and name that endpoint in your answer. Whichever mode you are in: the reader cannot tell a live value from a quoted one unless you say where it came from. This is wording in the final answer, not an extra step.

  • Produce every artefact the user asked for, under the name they used. Running the right API calls is not a substitute for the requested report: if the request names a deliverable, emit it, and keep its heading even when the finding is "none" or "not applicable".

PREFER
  • The narrowest mode that satisfies the request.

  • Reading exactly ONE mode reference. Load a second only when the request genuinely spans modes, and say so before you do.

  • Reporting the mode you chose in your first response so the user can correct you.

AVOID
  • Acting from this dispatcher alone -- it intentionally omits the operational detail.

  • Answering with a summary of the reference instead of executing it.

  • Re-reading or re-grepping a reference you already loaded; it costs turns and tokens.

  • Mutating anything while in a read-only mode.

  • Loading a different skill for work this skill already owns (see CRITICAL NOTES 3).

Examples

User requestModeReference to read
"Show me the refresh history and parameters of the SalesIngest dataflow."consumptionreferences/consumption.md
"Preview this M query, then save it into the SalesIngest dataflow definition."authoringreferences/authoring.md
"Is my Gen1 dataflow ready to upgrade to Gen2.1?"upgradereferences/upgrade.md

Files

references/authoring/authoring-cli-quickref.md

Authoring CLI Quick Reference

Concise az rest invocation patterns for Dataflows Gen2 authoring, base64 helpers, definition manipulation, and agent tips. For full API patterns and M code structure, see DATAFLOWS-AUTHORING-CORE.md. For full reusable scripts, see authoring-script-templates.md.

All examples assume reusable connection variables are set:

WS_ID="<workspaceId>"
DF_ID="<dataflowId>"
API="https://api.fabric.microsoft.com/v1"
RESOURCE="https://api.fabric.microsoft.com"

Cross-shell --body rule — bash snippets below use inline --body "{...}" for brevity, but on Windows / PowerShell that pattern breaks: az.exe is launched through cmd.exe's argument parser, which mangles embedded quotes and corrupts base64 payloads. For any non-trivial body (anything with quotes, newlines, or base64), write the JSON to a temp file and pass --body "@<path>". PowerShell-safe write that avoids a UTF-8 BOM: [IO.File]::WriteAllText("$env:TEMP\body.json", $json, [Text.UTF8Encoding]::new($false)). Full PowerShell create template (workload-specific /dataflows endpoint, no type field needed): authoring-script-templates.md § PowerShell — Create Dataflow with Definition.

Core Authoring via CLI

Create Dataflow (Empty)
az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows" \
  --body '{"displayName":"MyDataflow","description":"Sales ETL dataflow"}'
Create Dataflow (With Definition)
# Prepare definition parts (base64-encode each file)
QM_B64=$(cat queryMetadata.json | base64 -w0)
MASHUP_B64=$(cat mashup.pq | base64 -w0)
PLATFORM_B64=$(cat .platform | base64 -w0)

az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows" \
  --body "{
    \"displayName\": \"MyDataflow\",
    \"definition\": {
      \"parts\": [
        {\"path\":\"queryMetadata.json\",\"payload\":\"$QM_B64\",\"payloadType\":\"InlineBase64\"},
        {\"path\":\"mashup.pq\",\"payload\":\"$MASHUP_B64\",\"payloadType\":\"InlineBase64\"},
        {\"path\":\".platform\",\"payload\":\"$PLATFORM_B64\",\"payloadType\":\"InlineBase64\"}
      ]
    }
  }"
Get Definition

⚠ LRO caveat: getDefinition can return 202 + Location (the body is empty on the initial response) instead of an inline 200. The one-liner below only works for the synchronous case. For production code, use the LRO-aware curl pattern in Validate All Connections in a Dataflow below, or copy the Fabric LRO Polling Pattern bash branch into your script.

# POST (not GET!) — happy-path one-liner; 200 only. See LRO caveat above.
az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/getDefinition"
Preview Before Save (executeQuery)

Preview a candidate Power Query M document against the dataflow's bound connections before persisting via updateDefinition. Surfaces syntax / source / credential errors at authoring time. Full bootstrap branch + auto-wrap rule + Arrow handling: mashup-preview.md. Full recipe + Arrow → CSV: dataflows-cli consumption mode § Query Evaluation.

# customMashupDocument MUST be a complete `section Section1; ... shared X = ...;` doc.
# QueryName MUST match a `shared` member in the document.
# Cap preview cost: include Table.FirstN / TOP N — strip before saving.

QUERY_NAME="Customers"
M_DOC='section Section1;
shared Customers = let
    Source = Sql.Database("srv","db"),
    T = Source{[Schema="dbo", Item="Customers"]}[Data],
    Limited = Table.FirstN(T, 100)
in Limited;'

# executeQuery returns raw Apache Arrow IPC bytes (NOT a JSON envelope) via az rest.
# Pass --output-file so az captures the binary cleanly; failures are embedded as
# {"Error":"..."} inside the stream and HTTP 200 alone does NOT mean success.
jq -n --arg q "$QUERY_NAME" --arg m "$M_DOC" \
  '{QueryName: $q, customMashupDocument: $m}' > preview-req.json

az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/executeQuery" \
  --body @preview-req.json \
  --output-file preview.arrow

if grep -q '"Error":"' preview.arrow; then
  echo "✗ Preview failed (embedded source error):"
  python3 -c "import re,sys; raw=open(sys.argv[1],'rb').read().decode('utf-8','replace'); m=re.search(r'\\{\"Error\":\"[^\"]+\"\\}', raw); print(m.group(0) if m else '(marker present, JSON not parsed)')" preview.arrow
  exit 1
fi
echo "✓ Preview OK — $(wc -c < preview.arrow) bytes captured."

Bootstrap (new credentialed dataflow): bind connections via a minimal updateDefinition save before previewing credentialed M — mashup-preview.md § Bootstrap branch.

Update Definition
# Always send all 3 parts — full replacement
az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/updateDefinition?updateMetadata=true" \
  --body @definition.json
Delete Dataflow
az rest --method delete \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID"
Trigger Refresh (Simple)
# jobType MUST be "Refresh" for dataflows. "Pipeline" returns 400 InvalidJobType.
az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/jobs/instances?jobType=Refresh" \
  --headers "Content-Length=0"
Trigger Refresh (With Parameters)
az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/jobs/instances?jobType=Refresh" \
  --body '{
    "executionData": {"executeOption": "ApplyChangesIfNeeded"},
    "parameters": [
      {"name":"ServerName","value":"prod.database.windows.net","type":"Automatic"},
      {"name":"StartDate","value":"2025-01-01","type":"Automatic"}
    ]
  }'
Rename Dataflow (Properties Only)
az rest --method patch \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID" \
  --body '{"displayName":"RenamedDataflow","description":"Updated description"}'

Connection Discovery and Validation

Critical: Always validate all connection IDs before triggering refresh. Nonexistent connections cause cryptic refresh failures.

List All Connections
# List all accessible connections
az rest --method get \
  --resource "$RESOURCE" \
  --url "https://api.fabric.microsoft.com/v1/connections" \
  --query "value[].{id:id, name:displayName, type:connectionDetails.type}" -o json
Find Connection by Name
# Find a connection by display name (may return multiple results)
CONN_NAME="MyDatabase"
az rest --method get \
  --resource "$RESOURCE" \
  --url "https://api.fabric.microsoft.com/v1/connections" \
  --query "value[?displayName=='$CONN_NAME'].{id:id, type:connectionDetails.type}" -o json
Find Connection by Type
# Find all SQL Server connections
az rest --method get \
  --resource "$RESOURCE" \
  --url "https://api.fabric.microsoft.com/v1/connections" \
  --query "value[?connectionDetails.type=='SQL'].{id:id, name:displayName}" -o json

# Find all Azure Blob Storage connections
az rest --method get \
  --resource "$RESOURCE" \
  --url "https://api.fabric.microsoft.com/v1/connections" \
  --query "value[?connectionDetails.type=='AzureBlobs'].id" -o tsv
Validate a Specific Connection Exists
CONN_ID="550e8400-e29b-41d4-a716-446655440000"

# List all connections and filter by ID
RESULT=$(az rest --method get \
  --resource "$RESOURCE" \
  --url "https://api.fabric.microsoft.com/v1/connections" \
  --query "value[?id=='$CONN_ID'] | [0] | {id:id, name:displayName, type:connectionDetails.type}" \
  -o json)

if [ "$RESULT" == "null" ] || [ -z "$RESULT" ]; then
  echo "❌ Connection not found: $CONN_ID"
  exit 1
else
  echo "✅ Connection found:"
  echo "$RESULT" | jq '.'
fi
Extract Connection IDs from Dataflow Definition

⚠ LRO caveat: the az rest --method post .../getDefinition call below is a happy-path one-liner that only works when the response is synchronous (200). For large definitions or under load the API returns 202 + Location; this snippet will then yield an empty/operation-status payload and jq will fail silently. Use the LRO-aware curl pattern in Validate All Connections in a Dataflow below, or copy the Fabric LRO Polling Pattern bash branch into your script before relying on this in production.

# Get definition, extract queryMetadata, then list all referenced connections
RESULT=$(az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/getDefinition" \
  --headers "Content-Length=0")

QUERY_META=$(echo "$RESULT" | jq -r '.definition.parts[] | select(.path=="queryMetadata.json") | .payload' | base64 -d)

# List all connection references
echo "$QUERY_META" | jq '.connections[] | {path:.path, connectionId:.connectionId}'
Validate All Connections in a Dataflow (Pre-Refresh Check)
#!/bin/bash
# Validate all connections referenced in a dataflow before refresh

WS_ID="<id>"
DF_ID="<id>"
RESOURCE="https://api.fabric.microsoft.com"

# getDefinition can return 200 (sync) or 202 + Location (LRO) — handle both.
TOKEN=$(az account get-access-token --resource "$RESOURCE" --query accessToken -o tsv)
GET_DEF_BODY=$(mktemp); GET_DEF_HDR=$(mktemp)
HTTP_CODE=$(curl -sS -X POST \
  -H "Authorization: Bearer $TOKEN" -H "Content-Length: 0" \
  "https://api.fabric.microsoft.com/v1/workspaces/$WS_ID/dataflows/$DF_ID/getDefinition" \
  -D "$GET_DEF_HDR" -o "$GET_DEF_BODY" -w "%{http_code}")
if [ "$HTTP_CODE" = "202" ]; then
  # Fabric LRO: poll operation state, then GET /result.
  # See authoring-script-templates.md § Fabric LRO Polling Pattern for the contract.
  LOCATION=$(tr -d '\r' < "$GET_DEF_HDR" | grep -i "^location:" | awk '{print $2}')
  RETRY=$(tr -d '\r' < "$GET_DEF_HDR" | grep -i "^retry-after:" | awk '{print $2}'); RETRY=${RETRY:-5}
  while :; do
    sleep "$RETRY"
    OP=$(az rest --method get --resource "$RESOURCE" --url "$LOCATION")
    case "$(echo "$OP" | jq -r '.status // empty')" in
      Succeeded) RESULT=$(az rest --method get --resource "$RESOURCE" --url "${LOCATION%/}/result"); break ;;
      Failed|Cancelled) echo "ERROR: getDefinition $(echo "$OP" | jq -r '.status')" >&2; exit 1 ;;
    esac
  done
else
  RESULT=$(cat "$GET_DEF_BODY")
fi
rm -f "$GET_DEF_BODY" "$GET_DEF_HDR"

QUERY_META=$(echo "$RESULT" | jq -r '.definition.parts[] | select(.path=="queryMetadata.json") | .payload' | base64 -d)

# List all connections once for efficiency
ALL_CONNECTIONS=$(az rest --method get \
  --resource "https://api.fabric.microsoft.com" \
  --url "https://api.fabric.microsoft.com/v1/connections" \
  --query "value" -o json)

MISSING=0
echo "Validating connections..."
# queryMetadata.json connections[].connectionId is a STRINGIFIED COMPOSITE
# of shape {"ClusterId":"…","DatasourceId":"…"}. The plain-GUID `id` returned
# by GET /v1/connections matches the DatasourceId field. Parse before comparing.
# Use process substitution so MISSING updates persist (a piped `... | while` runs in a subshell).
while IFS= read -r row; do
  RAW_CONN_ID=$(echo "$row" | jq -r '.connectionId')
  CONN_PATH=$(echo "$row" | jq -r '.path')

  DATASOURCE_ID=$(echo "$RAW_CONN_ID" | jq -r '.DatasourceId? // empty' 2>/dev/null)
  [ -z "$DATASOURCE_ID" ] && DATASOURCE_ID="$RAW_CONN_ID"

  CONN_NAME=$(echo "$ALL_CONNECTIONS" | jq -r ".[] | select(.id==\"$DATASOURCE_ID\") | .displayName" 2>/dev/null || echo "")

  if [ -z "$CONN_NAME" ]; then
    echo "❌ $CONN_PATH: $DATASOURCE_ID NOT FOUND"
    MISSING=$((MISSING + 1))
  else
    echo "✅ $CONN_PATH: $DATASOURCE_ID ($CONN_NAME)"
  fi
done < <(echo "$QUERY_META" | jq -c '.connections[]')

if [ $MISSING -gt 0 ]; then
  echo "⚠️  Validation failed: $MISSING missing connection(s)"
  exit 1
else
  echo "✅ All connections validated"
fi

Base64 Encoding Helpers

Bash
# Encode file to base64 (no line wrapping)
base64 -w0 < mashup.pq

# Decode base64 payload to file
echo "<base64string>" | base64 -d > mashup.pq

# Extract and decode a specific part from getDefinition response
echo "$RESPONSE" | jq -r '.definition.parts[] | select(.path=="mashup.pq") | .payload' | base64 -d
PowerShell
# Encode file to base64
[Convert]::ToBase64String([System.IO.File]::ReadAllBytes("mashup.pq"))

# Decode base64 to file
[System.IO.File]::WriteAllBytes("mashup.pq", [Convert]::FromBase64String($base64String))

# Encode string content (UTF-8, no BOM)
[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($content))

Definition Manipulation Patterns

Read-Modify-Write Workflow

⚠ LRO caveat: the one-liner getDefinition below assumes a synchronous 200 response. Under load or for large definitions the API returns 202 + Location, which this snippet does not handle — it will silently fail and decode garbage. For production, use the LRO-aware curl pattern in Validate All Connections in a Dataflow above, or copy the Fabric LRO Polling Pattern bash branch into your script.

# 1. Get current definition (happy path; 200 only)
RESULT=$(az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/getDefinition")

# 2. Extract and decode each part
echo "$RESULT" | jq -r '.definition.parts[] | select(.path=="queryMetadata.json") | .payload' | base64 -d > queryMetadata.json
echo "$RESULT" | jq -r '.definition.parts[] | select(.path=="mashup.pq") | .payload' | base64 -d > mashup.pq
echo "$RESULT" | jq -r '.definition.parts[] | select(.path==".platform") | .payload' | base64 -d > .platform

# 3. Edit files as needed (e.g., modify mashup.pq)

# 4. Re-encode and build update payload
QM_B64=$(base64 -w0 < queryMetadata.json)
MASHUP_B64=$(base64 -w0 < mashup.pq)
PLATFORM_B64=$(base64 -w0 < .platform)

jq -n \
  --arg qm "$QM_B64" --arg mash "$MASHUP_B64" --arg plat "$PLATFORM_B64" \
  '{definition:{parts:[
    {path:"queryMetadata.json",payload:$qm,payloadType:"InlineBase64"},
    {path:"mashup.pq",payload:$mash,payloadType:"InlineBase64"},
    {path:".platform",payload:$plat,payloadType:"InlineBase64"}
  ]}}' > definition.json

# 5. Update
az rest --method post \
  --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/updateDefinition?updateMetadata=true" \
  --body @definition.json
LRO Polling Helper
# Poll operation until terminal status. Accepts both enum sets:
#   - LRO operation status (getDefinition/updateDefinition/async create): Succeeded
#   - Job instance status (refresh jobs): Completed
# Both have the same terminal Failed / Cancelled values.
poll_operation() {
  local url="$1"
  while true; do
    STATUS=$(az rest --method get --resource "$RESOURCE" --url "$url" --query "status" --output tsv)
    echo "Status: $STATUS"
    case "$STATUS" in
      Succeeded|Completed|Failed|Cancelled) break ;;
      *) sleep 10 ;;
    esac
  done
  echo "Final status: $STATUS"
}
Status Enum Reference — LRO Operation vs Job Instance

Fabric returns two different status enums depending on which endpoint you polled. Conflating them produces infinite polling loops or silently treats a still-running operation as terminal.

Polled URL came from…Endpoint examplesEnum values (live-verified 2026-05-13)Terminal-success value
LRO operation (Location header from a long-running endpoint)POST /…/getDefinition, POST /…/updateDefinition, async POST /…/dataflows (202 + Location)Running / Succeeded / Failed / CancelledSucceeded
Job instance (Location header from /jobs/instances?jobType=…)POST /…/dataflows/{id}/jobs/instances?jobType=Refresh, POST /…/items/{id}/jobs/instances?jobType=PipelineNotStarted / InProgress / Completed / Failed / CancelledCompleted

Rule of thumb: if the URL the agent is polling came from …/jobs/instances/…, the terminal-success value is Completed; otherwise it is Succeeded. Failed and Cancelled are valid terminal failures in both enums.

Connection Creation Quick Patterns

For the full decision tree, schemas per credential type, and pitfalls, see connection-management.md.

List supported connection types (always do this before POST /v1/connections):

az rest --method get --resource "$RESOURCE" \
  --url "$API/connections/supportedConnectionTypes" \
  --query "value[?type=='SQL']"

Create cloud SQL connection (Basic auth, Key Vault-backed password):

az rest --method post --resource "$RESOURCE" --url "$API/connections" --body '{
  "connectivityType": "ShareableCloud",
  "displayName": "ContosoSqlConnection",
  "connectionDetails": {
    "type": "SQL", "creationMethod": "SQL",
    "parameters": [
      {"dataType":"Text","name":"server","value":"contoso.database.windows.net"},
      {"dataType":"Text","name":"database","value":"sales"}
    ]
  },
  "privacyLevel": "Organizational",
  "credentialDetails": {
    "singleSignOnType": "None",
    "connectionEncryption": "Encrypted",
    "skipTestConnection": false,
    "credentials": {
      "credentialType": "Basic",
      "username": "admin",
      "passwordReference": {"connectionId":"<kvConnId>","secretName":"sql-pwd"}
    }
  }
}'

Create cloud Lakehouse connection (Workspace identity):

az rest --method post --resource "$RESOURCE" --url "$API/connections" --body '{
  "connectivityType": "ShareableCloud",
  "displayName": "ContosoLakehouseConnection",
  "connectionDetails": {
    "type": "Lakehouse", "creationMethod": "Lakehouse",
    "parameters": [
      {"dataType":"Text","name":"workspaceId","value":"<wsId>"},
      {"dataType":"Text","name":"lakehouseId","value":"<lhId>"}
    ]
  },
  "privacyLevel": "Organizational",
  "credentialDetails": {
    "singleSignOnType": "None",
    "connectionEncryption": "Encrypted",
    "skipTestConnection": false,
    "credentials": {"credentialType":"WorkspaceIdentity"}
  }
}'

Capture the new connection's plain-GUID id directly from the response:

NEW_CONN_ID=$(az rest --method post --resource "$RESOURCE" \
  --url "$API/connections" --body @body.json \
  --query "id" --output tsv)

Connector parameters and supported credentials vary by tenant, gateway, and over time. Treat the snippets above as illustrative; supportedConnectionTypes is authoritative.

Connection Binding Quick Patterns

Get current definition (handles both 200 sync and 202 LRO):

# az rest cannot return response headers; use curl with an az-acquired token to capture Location.
TOKEN=$(az account get-access-token --resource "$RESOURCE" --query accessToken -o tsv)
HDR=$(mktemp); BODY=$(mktemp)
CODE=$(curl -sS -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Length: 0" \
  "$API/workspaces/$WS_ID/dataflows/$DF_ID/getDefinition" \
  -D "$HDR" -o "$BODY" -w "%{http_code}")
if [ "$CODE" = "202" ]; then
  # Fabric LRO: poll operation state, then GET /result.
  # See authoring-script-templates.md § Fabric LRO Polling Pattern for the contract.
  LOCATION=$(tr -d '\r' < "$HDR" | grep -i "^location:" | awk '{print $2}')
  RETRY=$(tr -d '\r' < "$HDR" | grep -i "^retry-after:" | awk '{print $2}'); RETRY=${RETRY:-5}
  while :; do
    sleep "$RETRY"
    OP=$(az rest --method get --resource "$RESOURCE" --url "$LOCATION")
    case "$(echo "$OP" | jq -r '.status // empty')" in
      Succeeded) DEF=$(az rest --method get --resource "$RESOURCE" --url "${LOCATION%/}/result"); break ;;
      Failed|Cancelled) echo "ERROR: getDefinition $(echo "$OP" | jq -r '.status')" >&2; exit 1 ;;
    esac
  done
else
  DEF=$(cat "$BODY")
fi
rm -f "$HDR" "$BODY"

Get ClusterId for a connection:

The endpoint lives on the Power BI control plane (not on api.fabric.microsoft.com) and the field is clusterId (camelCase). Pass --resource "https://analysis.windows.net/powerbi/api" to get the right token audience.

CONN_ID="<connectionId>"
PBI_RESOURCE="https://analysis.windows.net/powerbi/api"

# Use the LIST endpoint and filter by `id`. The per-id route
# (.../gatewayClusterDatasources/$CONN_ID) returns PowerBIEntityNotFound for
# cloud connections; list+filter is the supported pattern. Newly-created
# connections may take a few seconds to surface here — retry if empty.
CLUSTER_ID=$(az rest --method get \
  --resource "$PBI_RESOURCE" \
  --url "https://api.powerbi.com/v2.0/myorg/me/gatewayClusterDatasources" \
  --query "value[?id=='$CONN_ID'] | [0].clusterId" --output tsv)

Extract queryMetadata.json from definition:

echo "$DEF" | jq -r '.definition.parts[] | select(.path=="queryMetadata.json") | .payload' | base64 --decode > queryMetadata.json

Add connection to queryMetadata.json (with ClusterId):

jq '.connections += [{
  "connectionId": "{\"ClusterId\": \"'$CLUSTER_ID'\", \"DatasourceId\": \"'$CONN_ID'\"}",
  "kind": "Sql",
  "path": "[dbo]"
}]' queryMetadata.json > queryMetadata_updated.json

Update dataflow with all 3 parts (full read-modify-write):

# Encode all parts
QM_B64=$(base64 -w0 < queryMetadata_updated.json)
MASHUP_B64=$(echo "$DEF" | jq -r '.definition.parts[] | select(.path=="mashup.pq") | .payload')
PLATFORM_B64=$(echo "$DEF" | jq -r '.definition.parts[] | select(.path==".platform") | .payload')

# Build the body in a temp file and pass via --body "@<path>".
# DO NOT use inline --body "{...}" with embedded base64 — cmd.exe argument parsing
# on Windows mangles the quotes and corrupts the payload. See SKILL.md MUST DO.
UPDATE_BODY=$(mktemp --suffix=.json 2>/dev/null || mktemp)
jq -n --arg qm "$QM_B64" --arg mp "$MASHUP_B64" --arg pf "$PLATFORM_B64" '{
  definition: { parts: [
    { path: "queryMetadata.json", payload: $qm, payloadType: "InlineBase64" },
    { path: "mashup.pq",          payload: $mp, payloadType: "InlineBase64" },
    { path: ".platform",          payload: $pf, payloadType: "InlineBase64" }
  ]}}' > "$UPDATE_BODY"

az rest --method post --resource "$RESOURCE" \
  --url "$API/workspaces/$WS_ID/dataflows/$DF_ID/updateDefinition" \
  --headers "Content-Type=application/json" \
  --body "@$UPDATE_BODY"
rm -f "$UPDATE_BODY"

See authoring-script-templates.md § Connection Binding Templates for complete end-to-end examples.

Agent Integration Notes

  • GitHub Copilot CLI: Generate az rest one-liners for dataflow CRUD or complete .sh scripts. Always include --resource "https://api.fabric.microsoft.com" in output. Remind user about base64 encoding for definition parts.

  • Claude Code / Cowork: Run az rest commands via bash tool directly. For definition manipulation: write files first, then encode and send. Always verify az login before first use. After updates: get definition again to confirm.

  • Common agent pattern:

    1. Discover workspace ID + dataflow ID

    2. Get current definition (decode all 3 parts)

    3. Formulate changes to M code or metadata

    4. Re-encode all 3 parts and update definition

    5. Optionally trigger refresh and poll for completion

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/skills-for-fabric · skills/dataflows-cli · commit f8fac11
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
microsoft/skills-for-fabric

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dataflows-cli.zip