/activator-cli

name: activator-cli
description: "Creates and inspects Fabric Activator (Reflex) alerts: rules, their data sources, conditions, and the Teams or email action they fire, plus decoding an existing ReflexEntities definition. Choose it whenever someone wants to be told, or something done, when values cross a threshold. The pipeline delivering those values is eventstream-cli."

> **Telemetry — MANDATORY.** Every `api.fabric.microsoft.com` call must carry > `x-ms-fabric-skill: activator-cli` (`az rest`: `--headers "x-ms-fabric-skill=activator-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 `activator-cli` for every Fabric Activator / Reflex item — both authoring alert rules and inspecting existing alerts. The streaming topology that feeds an alert belongs to `eventstream-cli`, the KQL database behind it to `eventhouse-cli`, and Power BI report questions to `fabriciq`.

Fabric Activator (Reflex) — CLI Skill

This one skill owns Fabric Activator / Reflex items: alert rules, their sources, their actions, and the `ReflexEntities.json` definition that holds them.

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, entity schemas, templates and gotchas; acting without it produces invalid `ReflexEntities.json` payloads and 400s.

The reference is needed to *act*, not to *ask*. If the request is under-specified and your next message will be a clarifying question with no Fabric call in it, ask it now and read the reference when you go on to act.

Mode selection

| Mode | Use when the request ... | Example triggers | Read this first | |---|---|---|---| | `authoring` | creates, updates, configures or deletes an Activator item, rule, source or action | create an alert, create an activator, create a reflex, notify me when, let me know when, take action when, send me an email when, send a teams message when, run a pipeline when, update an alert, delete an alert | [references/authoring.md](references/authoring.md) | | `consumption` | lists, inspects, decodes or explains existing Activators, rules, sources or actions | show my alerts, what alerts do I have, list activators, inspect this alert, show me the rule, show me the source, get reflex definition, why does this alert fire | [references/consumption.md](references/consumption.md) |

Mode boundary rule

`consumption` is read-only. A request to create, update, configure or delete an Activator item, rule, source or action requires `authoring`: say so, read `references/authoring.md`, then proceed.

A pure GET / explain request stays in `consumption` — do not switch to `authoring` and do not mutate anything to answer it.

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, decoding a definition and assembling entities is NOT completing the task. Authoring ends with one state-changing call. If you did not issue it, nothing was persisted — say so explicitly rather than reporting success.

| Mode | Terminal write | |---|---| | `authoring` | `POST /v1/workspaces/{ws}/reflexes` to create the item, `POST /v1/workspaces/{ws}/reflexes/{id}/updateDefinition` to persist rules, sources and actions, or `DELETE /v1/workspaces/{ws}/reflexes/{id}` to remove it. Building, stringifying or base64-encoding `ReflexEntities.json` is not the write. | | `consumption` | none — this mode is read-only |

Before you report an authoring task done, confirm the terminal call returned an explicit success (HTTP `200`/`201`, or a terminal LRO success for a `202`), then read the definition back where the mode reference documents a readback. Power BI sources are the exception: public ALM export can reject an artifact that imported successfully, so an empty or unavailable readback is **not** proof the write failed — report the `updateDefinition` result and the readback limitation separately, per [references/authoring/powerbi-source.md](references/authoring/powerbi-source.md).

Source validation gate (authoring only)

Before authoring any rule that references a signal, confirm the source is real: **resolve** it in the requested workspace only, **validate** that the requested column/field/property exists on it, and **observe** at least one representative row, event or sample carrying that signal.

Schema-only, zero-row, non-emitting or stale evidence is **missing source data**. When the source is missing, **stop and ask** which source and fields provide the signal — do not create a Reflex and do not call `updateDefinition` on an unrelated existing Activator or Eventstream to force-fit the request, and state plainly that no Activator / Reflex / Eventstream was created or updated. The only exception is an explicit instruction to author against a future / not-yet-emitting source, which you must state as an assumption.

Everything you need to run this gate is on this page. When the request already lacks the source mapping, threshold, recipients or action target, ask for them **first** — do not read `references/authoring.md`, and do not call a Fabric API, just to discover that the request is under-specified.

Shared essentials (all modes)

Resolve the workspace and the Activator item first; every mode depends on it — list and