Generated banner for Activator CLI
Generated logo for Activator CLI

Activator CLI

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Tool integration
  • Data and AI
  • MIT
  • Low risk

From the author

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.
— the description by Microsoft

AutoGineer summary

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

The activator-cli skill provides a structured interface for interacting with Microsoft Fabric Activator (Reflex) items. It acts as a mode-based dispatcher that separates authoring tasks (creating, updating, or deleting alert rules, sources, and actions) from consumption tasks (listing, inspecting, and decoding existing definitions). The skill enforces strict validation gates for data sources and requires specific handling of JSON payloads to ensure compatibility with Fabric APIs.

What it does

  • Creates and configures Activator alert rules and data sources.
  • Defines automated actions including Teams notifications, emails, and Fabric item invocations.
  • Inspects and decodes existing ReflexEntities definitions.
  • Lists and filters workspaces and Activator items for management.
  • Validates data sources and signals before rule authoring.
  • Manages the lifecycle of Reflex items through REST API operations.

When to use it

  • When you need to set up automated alerts based on data thresholds.
  • When you need to inspect or audit existing alert rules and their configurations.
  • When you need to integrate Fabric Activator with Teams or email for operational notifications.
  • When you need to programmatically manage Reflex item definitions.

Advantages

  • Provides a clear separation between read-only inspection and state-changing authoring.
  • Includes built-in validation gates to prevent invalid rule creation.
  • Supports complex alert logic including transition-based detectors.
  • Standardizes the handling of Fabric API authentication and telemetry.

Usage examples

“Create an Activator named sales_alert in my workspace.”
The agent will switch to authoring mode, read the authoring reference, and execute the POST request to create the Reflex item.
“Show me all Activators in this workspace.”
The agent will use consumption mode to list and filter the Reflex items within the specified workspace.
“Notify me on Teams when the average temperature goes above 30.”
The agent will validate the temperature source, configure the rule condition, and set up the TeamsMessage action.
“What rule and action are behind SkillsTestActivator?”
The agent will use consumption mode to retrieve and decode the ReflexEntities definition for the specified item.

Install

  1. Download the skill as a ZIP:

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

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

Documentation by Microsoft

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

ModeUse when the request ...Example triggersRead this first
authoringcreates, updates, configures or deletes an Activator item, rule, source or actioncreate 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 alertreferences/authoring.md
consumptionlists, inspects, decodes or explains existing Activators, rules, sources or actionsshow 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 firereferences/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.

ModeTerminal write
authoringPOST /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.
consumptionnone — 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.

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 filter by display name exactly as CRITICAL NOTES 1 and 2 describe. That recipe is self-contained and is all you need to start.

The table below is optional background living in the shared common/ docs. Open a row only when you actually need that detail. If common/ is not present in your environment, say so in one line and continue with the mode reference — never glob, list or search the filesystem looking for it.

TaskReferenceNotes
Finding Workspaces and Items in FabricCOMMON-CLI.mdPagination and JMESPath filtering detail
Fabric Topology & Key ConceptsCOMMON-CORE.mdItem types, workspaces, capacities
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
Fabric Item DefinitionsITEM-DEFINITIONS-CORE.mdBase64-encoded parts structure
Gotchas & TroubleshootingCOMMON-CLI.mdaz rest audience, shell escaping, token expiry

Activator uses the reflexes collection, not the generic items collection: /v1/workspaces/{workspaceId}/reflexes[/{reflexId}].

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. A reply that only asks a clarifying question, and issues no Fabric call, does not need it yet.

  • Pass --resource https://api.fabric.microsoft.com on every az rest call — without it the token audience is wrong and the call returns 401.

  • Call getDefinition as a POST with --body '{}', then Base64-decode the ReflexEntities.json part before inspecting it; a GET returns 405 and an omitted body can return 411.

  • Poll the Location header when create, getDefinition or updateDefinition returns 202.

  • Resolve workspace and Activator 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.

  • In authoring, clear the source validation gate before you author a rule, and build ReflexEntities.json with Python json.dumps() — PowerShell's ConvertTo-Json corrupts the nested JSON strings that definition.instance requires.

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.

  • Read-modify-write over full replacement in authoring: get the current definition, modify the entity array, then update.

  • Transition-based detectors (NumberBecomes, NumberEntersOrLeavesRange, LogicalBecomes) over steady-state conditions in authoring, unless the user explicitly asks for repeated firing while the value stays in the triggered state.

  • A summary view before individual entities in consumption: give the high-level picture, then drill in.

  • Offering an alert when earlier work in this session surfaced a timely operational signal — a spike, failure, anomaly, SLA risk or capacity constraint — rather than waiting to be asked. Ask once, and author nothing until the user agrees.

AVOID
  • Acting from this dispatcher alone — it intentionally omits the entity schemas and templates.

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

  • Mutating anything while in the read-only consumption mode, including "just to check".

  • Hardcoded workspace or item ids in either mode — always resolve dynamically.

  • Globbing, listing or shell-searching the filesystem for the common/ docs. They are optional background; if a link does not resolve, note it in one line and carry on.

  • Building the Eventstream topology that feeds an alert here; that is eventstream-cli. Querying the KQL data behind an alert is eventhouse-cli.

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

Examples

User requestModeReference to read
"Create an Activator named eval_smoke_activator in my workspace."authoringreferences/authoring.md
"Notify me on Teams when the average temperature goes above 30."authoringreferences/authoring.md
"Delete the alert that emails me about failed pipeline runs."authoringreferences/authoring.md
"Show me all Activators in this workspace."consumptionreferences/consumption.md
"What rule and action are behind SkillsTestActivator?"consumptionreferences/consumption.md
"Decode this Reflex definition and explain the Power BI source."consumptionreferences/consumption.md

Files

references/authoring/rule-conditions.md

Activator Rule Conditions — timeSeriesView-v1 Templates & Rule Logic

⚠️ Every template-backed timeSeriesView-v1 entity MUST be wrapped in a timeSeriesView-v1 entity envelope with the template JSON.stringify'd into definition.instance. Never output a raw template — always output the full entity.


This reference covers the template-backed timeSeriesView-v1 entities used in Activator definitions:

  • Rule views (definition.type = "Rule")

  • Event views such as SourceEvent and SplitEvent (definition.type = "Event")

  • Attribute views such as IdentityPartAttribute and BasicEventAttribute (definition.type = "Attribute")

Rules are the main focus because this file explains condition rows, detectors, aggregation, occurrence options, and actions, but the same timeSeriesView-v1 envelope and template conventions also apply to the other view types listed below.

Rule view entity envelope

Rules are timeSeriesView-v1 entities with definition.type = "Rule":

{
  "uniqueIdentifier": "<guid>",
  "payload": {
    "name": "Too hot for medicine",
    "description": "Created by: skills-for-fabric",
    "parentObject": { "targetUniqueIdentifier": "<object-guid>" },
    "parentContainer": { "targetUniqueIdentifier": "<container-guid>" },
    "definition": {
      "type": "Rule",
      "instance": "<JSON-encoded template — MUST be a string, not nested object>",
      "settings": { "shouldRun": true, "shouldApplyRuleOnUpdate": false }
    }
  },
  "type": "timeSeriesView-v1"
}

Critical: definition.instance is a JSON-encoded string. You must JSON.stringify() the template object and set it as a string value, not a nested object.

For user clarity, add payload.description: "Created by: skills-for-fabric" to rule entities.

Settings: shouldRun (boolean — is rule active), shouldApplyRuleOnUpdate (boolean — re-evaluate on definition update).

Default new rules to shouldRun: true so they start in the started / running state. Use shouldRun: false only when the user explicitly wants a stopped rule or when a safe verification workflow intentionally requires a disabled rule.


Rule Template Structure

Template version: Default newly authored rules to 1.2.4 unless backend guidance or a known-good readback requires a newer version. Features such as Fabric item parameters require at least 1.2, and flexible item types / UDF subitemId require at least 1.2.3, so 1.2.4 covers the known public requirements. When modifying an existing source-created graph, preserve the existing template shape unless the new rows require a newer version.

{ "templateId": "AttributeTrigger", "templateVersion": "1.2.4",
  "steps": [
    { "name": "ScalarSelectStep", "id": "<guid>", "rows": [...] },
    { "name": "ScalarDetectStep", "id": "<guid>", "rows": [...] },
    { "name": "DimensionalFilterStep", "id": "<guid>", "rows": [...] },
    { "name": "ActStep", "id": "<guid>", "rows": [...] }
  ]
}
Template IDs
templateIdUsed ForStep Sequence
AttributeTriggerRule viewsScalarSelectStep → ScalarDetectStep → (DimensionalFilterStep)* → ActStep
EventTriggerRule viewsFieldsDefaultsStep → (EventDetectStep)+ → (DimensionalFilterStep)* → ActStep
SourceEventEvent viewsSourceEventStep
SplitEventEvent viewsSplitEventStep
IdentityPartAttributeAttribute viewsIdPartStep
BasicEventAttributeAttribute viewsEventSelectStep → EventComputeStep
Step Sequence Notation
  • * means zero or more

  • + means one or more

Minimal EventTrigger Entity Graph

For pure event-trigger scenarios, the minimal valid graph is:

Container -> Source -> SourceEvent -> Rule
                        \
                         -> (optional) fabricItemAction-v1

Do not add Object, SplitEvent, IdentityPartAttribute, or BasicEventAttribute entities unless you are intentionally switching to attribute-based modeling.

Required FieldsDefaultsStep

Every EventTrigger must begin with exactly one EventSelector row. The EventReference is nested inside that selector and points to the SourceEvent entity. Do not place an EventReference row directly in FieldsDefaultsStep; RSA rejects that shape with InvalidTemplateInstance.

{
  "name": "FieldsDefaultsStep",
  "id": "<guid>",
  "rows": [
    {
      "name": "EventSelector",
      "kind": "Event",
      "arguments": [
        {
          "name": "event",
          "kind": "EventReference",
          "type": "complex",
          "arguments": [
            {
              "name": "entityId",
              "type": "string",
              "value": "<source-event-entity-guid>"
            }
          ]
        }
      ]
    }
  ]
}
EventDetectStep Branches

Use exactly ONE branch per step:

BranchRowsUse Case
EventHeartbeatDetectorOnEveryValue or NoHeartbeat aloneFire on every event, or detect missing events
EventStateDetectorEventFieldSelector + state conditionFire when event field meets condition
EventChangeDetectorEventFieldSelector + change conditionFire when event field changes

OnEveryValue:

{ "name": "EventDetectStep", "id": "<guid>",
  "rows": [{ "name": "OnEveryValue", "kind": "OnEveryValue", "arguments": [] }] }

NoHeartbeat (fire when events STOP — e.g., 5min = 300000ms):

{ "name": "EventDetectStep", "id": "<guid>",
  "rows": [{ "name": "NoHeartbeat", "kind": "NoHeartbeat",
    "arguments": [{ "name": "duration", "type": "timeSpan", "value": 300000 }] }] }

EventStateDetector (field + state condition):

{ "name": "EventDetectStep", "id": "<guid>",
  "rows": [
    { "name": "EventFieldSelector", "kind": "EventField",
      "arguments": [{ "name": "fieldName", "type": "string", "value": "severity" }] },
    { "name": "TextValueCondition", "kind": "TextValueCondition",
      "arguments": [
        { "name": "op", "type": "string", "value": "IsEqualTo" },
        { "name": "value", "type": "string", "value": "Error" }] }
  ] }

State conditions: NumberValueCondition, NumberRangeCondition, TextValueCondition, TextLengthCondition, LogicalValueCondition.

EventChangeDetector (field + change condition):

{ "name": "EventDetectStep", "id": "<guid>",
  "rows": [
    { "name": "EventFieldSelector", "kind": "EventField",
      "arguments": [{ "name": "fieldName", "type": "string", "value": "status" }] },
    { "name": "AnyValueChange", "kind": "AnyValueChange",
      "arguments": [{ "name": "op", "type": "string", "value": "Changes" }] }
  ] }

Change conditions: NumberBecomes, NumberEntersOrLeavesRange, NumberChanges, NumberTrendsBy, TextChanges, LogicalBecomes, AnyValueChange.

⚠️ Common mistakes: A top-level EventReference row in FieldsDefaultsStep is invalid; wrap it in the required EventSelector row. EachTime is an OccurrenceOption for AttributeTrigger's ScalarDetectStep — NOT valid in EventDetectStep. A bare AnyValueChange without EventFieldSelector before it causes RowCountMismatch. Another common mistake is overbuilding an Object/SplitEvent/Attribute graph for a rule that should just use SourceEvent + EventTrigger.


Row Kinds Quick Reference

State Conditions (fires while condition holds)
kindop valuesArguments
NumberValueConditionIsEqualTo, IsNotEqualTo, IsGreaterThan, IsGreaterThanOrEqualTo, IsLessThan, IsLessThanOrEqualToop (string), threshold (number)
NumberRangeConditionIsInsideRange, IsOutsideRangeop (string), low (number), includeLow (boolean), high (number), includeHigh (boolean)
TextValueConditionIsEqualTo, IsNotEqualTo, BeginsWith, Contains, EndsWith, DoesNotBeginWith, DoesNotContain, DoesNotEndWithop (string), value (string)
TextLengthConditionHasLengthGreaterThan, HasLengthGreaterThanOrEqualTo, HasLengthLessThan, HasLengthLessThanOrEqualTo, HasLengthEqualTo, HasLengthNotEqualToop (string), length (number)
LogicalValueConditionIsEqual, IsNotEqualop (string), value (boolean)
Change Conditions (fires on transition)
kindop valuesArguments
NumberBecomesBecomesGreaterThan, BecomesGreaterThanOrEqualTo, BecomesLessThan, BecomesLessThanOrEqualToop (string), value (number)
NumberEntersOrLeavesRangeEntersRange, LeavesRangeop (string), low (number), includeLow (boolean), high (number), includeHigh (boolean)
NumberChangesChangesFrom, ChangesToop (string), value (number)
NumberChangesFromTo(no op)oldValue (number), newValue (number)
NumberTrendsByDecreasesByAtLeast, IncreasesByAtLeast, ChangesByAtLeastop (string), offset (number), inPercent (boolean)
TextChangesChangesFrom, ChangesToop (string), value (string)
TextChangesFromTo(no op)oldValue (string), newValue (string)
LogicalBecomesBecomesTrue, BecomesFalseop (string)
AnyValueChangeChangesop (string)
Heartbeat Conditions
kindArguments
NoHeartbeatduration (timeSpan)
OnFirstHeartbeatduration (timeSpan, optional)
Occurrence Options (optional, follows a detection row in ScalarDetectStep)
kindDescriptionArguments
EachTimeFire every time condition is met(none)
ForNthTimeFire after N occurrences within a windown (number), duration (timeSpan)
State Detector Option (optional, follows a state condition)
kindDescriptionArguments
SustainedPeriodOptionCondition must persist for a duration before firingperiod (timeSpan)

ScalarSelectStep — Attribute Selection & Aggregation

Attribute Reference
{ "name": "AttributeSelector", "kind": "Attribute",
  "arguments": [{
    "kind": "AttributeReference", "type": "complex", "name": "attribute",
    "arguments": [{ "name": "entityId", "type": "string", "value": "<attribute-entity-guid>" }]
  }] }
Aggregation (NumberSummary)
{ "name": "NumberSummary", "kind": "NumberSummary",
  "arguments": [
    { "name": "op", "type": "string", "value": "Average" },
    { "kind": "TimeDrivenWindowSpec", "type": "complex", "name": "window",
      "arguments": [
        { "name": "width", "type": "timeSpan", "value": 600000.0 },
        { "name": "hop", "type": "timeSpan", "value": 600000.0 }
      ] }
  ] }

Aggregation ops: Average, Sum, Min, Max, Count.

Time Windows (TimeDrivenWindowSpec)

Values in milliseconds: 1min=60000, 5min=300000, 10min=600000, 30min=1800000, 1hr=3600000, 6hr=21600000, 24hr=86400000.

width = window size. hop = advance interval (= width for tumbling, smaller for sliding).


ScalarDetectStep — Detection Conditions

Accepts one detection row (state or change — see Quick Reference), plus an optional occurrence modifier.

Default alerting preference: for most notification scenarios, prefer change / transition detectors over steady-state detectors. Use NumberBecomes, NumberEntersOrLeavesRange, LogicalBecomes, or other explicit change conditions even when the user uses state-like wording such as "is greater than", "is below", or "is outside the normal range". Interpret ordinary alert wording as "notify me when it crosses into that state". Reserve steady-state conditions like IsGreaterThan, IsLessThan, and IsOutsideRange for cases where repeated firing while the condition remains true is intentionally desired, such as "notify me every time it is greater than 30" or "fire on every evaluation while it is above 30".

NumberValueCondition

Note: Uses threshold (not value) as argument name.

{ "name": "NumberValueCondition", "kind": "NumberValueCondition",
  "arguments": [
    { "name": "op", "type": "string", "value": "IsGreaterThan" },
    { "name": "threshold", "type": "number", "value": 25.0 }] }
NumberBecomes

Fires only on transition, not while condition remains true:

{ "name": "NumberBecomes", "kind": "NumberBecomes",
  "arguments": [
    { "name": "op", "type": "string", "value": "BecomesGreaterThan" },
    { "name": "value", "type": "number", "value": 30.0 }] }

Use BecomesGreaterThan / BecomesLessThan when the goal is to avoid alert spam from repeated evaluations of the same high / low state.

NumberEntersOrLeavesRange (change) & NumberRangeCondition (state)

⚠️ Range change uses NumberEntersOrLeavesRange, NOT NumberBecomes. Range state uses NumberRangeCondition.

Both share args: op, low (number), includeLow (boolean), high (number), includeHigh (boolean).

{ "name": "NumberEntersOrLeavesRange", "kind": "NumberEntersOrLeavesRange",
  "arguments": [
    { "name": "op", "type": "string", "value": "LeavesRange" },
    { "name": "low", "type": "number", "value": 10.0 },
    { "name": "high", "type": "number", "value": 25.0 },
    { "name": "includeLow", "type": "boolean", "value": true },
    { "name": "includeHigh", "type": "boolean", "value": true }] }

For state: use kind NumberRangeCondition with ops IsInsideRange / IsOutsideRange.

For most alerting scenarios, prefer EntersRange / LeavesRange over IsInsideRange / IsOutsideRange so the rule fires when the value crosses the boundary rather than on every subsequent evaluation while it remains in-range or out-of-range.

TextValueCondition
{ "name": "TextValueCondition", "kind": "TextValueCondition",
  "arguments": [
    { "name": "op", "type": "string", "value": "IsEqualTo" },
    { "name": "value", "type": "string", "value": "Critical" }] }

For prompts like "alert when more than 10 ERROR readings occur in 5 minutes", select the text/status attribute, use TextValueCondition with an op such as IsEqualTo, then add an OccurrenceOption row. Do not model this as NumberSummary / Count over the text attribute, and do not put count operators into TextValueCondition.op; the backend expects text conditions to receive text operators and will reject mismatched count/numeric encodings.

{ "name": "ScalarDetectStep", "id": "<guid>",
  "rows": [
    { "name": "TextValueCondition", "kind": "TextValueCondition",
      "arguments": [
        { "name": "op", "type": "string", "value": "IsEqualTo" },
        { "name": "value", "type": "string", "value": "ERROR" }] },
    { "name": "OccurrenceOption", "kind": "ForNthTime",
      "arguments": [
        { "name": "n", "type": "number", "value": 11 },
        { "name": "duration", "type": "timeSpan", "value": 300000 }] }
  ] }

Use n = threshold + 1 for "more than N" wording. For example, "more than 10 ERROR readings" maps to ForNthTime with n = 11 in the 5-minute window.

TextLengthCondition
{ "name": "TextLengthCondition", "kind": "TextLengthCondition",
  "arguments": [
    { "name": "op", "type": "string", "value": "HasLengthGreaterThan" },
    { "name": "length", "type": "number", "value": 100 }] }
LogicalBecomes (change) & LogicalValueCondition (state)

Attribute must use "Logical" TypeAssertion.

{ "name": "LogicalBecomes", "kind": "LogicalBecomes",
  "arguments": [{ "name": "op", "type": "string", "value": "BecomesTrue" }] }
{ "name": "LogicalValueCondition", "kind": "LogicalValueCondition",
  "arguments": [
    { "name": "op", "type": "string", "value": "IsEqual" },
    { "name": "value", "type": "boolean", "value": false }] }
NumberTrendsBy

⚠️ Row name ≠ kind: name is "NumberTrends", kind is "NumberTrendsBy". Wrong name causes API rejection.

{ "name": "NumberTrends", "kind": "NumberTrendsBy",
  "arguments": [
    { "name": "op", "type": "string", "value": "IncreasesByAtLeast" },
    { "name": "offset", "type": "number", "value": 10.0 },
    { "name": "inPercent", "type": "boolean", "value": false }] }

Set inPercent: true for percentage-based trends.

Value Change Detection

⚠️ Row name ≠ kind for FromTo variants: NumberChangesFromTo and TextChangesFromTo kinds use row names "NumberChanges" and "TextChanges" respectively.

{ "name": "NumberChanges", "kind": "NumberChanges",
  "arguments": [
    { "name": "op", "type": "string", "value": "ChangesTo" },
    { "name": "value", "type": "number", "value": 0 }] }
{ "name": "TextChanges", "kind": "TextChanges",
  "arguments": [
    { "name": "op", "type": "string", "value": "ChangesTo" },
    { "name": "value", "type": "string", "value": "ERROR" }] }
{ "name": "AnyValueChange", "kind": "AnyValueChange",
  "arguments": [{ "name": "op", "type": "string", "value": "Changes" }] }
Name ≠ Kind Reference
Row Name (name)Picker Kind (kind)
NumberTrendsNumberTrendsBy
NumberChangesNumberChanges or NumberChangesFromTo
TextChangesTextChanges or TextChangesFromTo
Heartbeat Conditions (AttributeTrigger ScalarDetectStep only)
{ "name": "OnFirstHeartbeat", "kind": "OnFirstHeartbeat", "arguments": [] }
{ "name": "NoHeartbeat", "kind": "NoHeartbeat",
  "arguments": [{ "name": "duration", "type": "timeSpan", "value": 300000 }] }

Occurrence Options

{ "name": "OccurrenceOption", "kind": "EachTime", "arguments": [] }
{ "name": "OccurrenceOption", "kind": "ForNthTime",
  "arguments": [
    { "name": "n", "type": "number", "value": 5 },
    { "name": "duration", "type": "timeSpan", "value": 3600000 }] }

SustainedPeriodOption — state detector option, placed after a state condition row:

{ "name": "SustainedPeriodOption", "kind": "SustainedPeriodOption",
  "arguments": [{ "name": "period", "type": "timeSpan", "value": 300000 }] }

DimensionalFilterStep — Additional Filters

Optional step filtering which objects the rule applies to. Uses same condition kinds as ScalarDetectStep.

{ "name": "DimensionalFilterStep", "id": "<guid>",
  "rows": [
    { "name": "AttributeSelector", "kind": "Attribute",
      "arguments": [{
        "kind": "AttributeReference", "type": "complex", "name": "attribute",
        "arguments": [{ "name": "entityId", "type": "string", "value": "<filter-attribute-guid>" }]
      }] },
    { "name": "TextValueCondition", "kind": "TextValueCondition",
      "arguments": [
        { "name": "op", "type": "string", "value": "IsEqualTo" },
        { "name": "value", "type": "string", "value": "Medicine" }] }
  ] }

Enrichments — Adding Context to Notifications

Enrichments are references to existing BasicEventAttribute entities placed in the rule's ActStep action binding. Create the attribute entity first, then reference it from the action payload.

⚠️ AttributeTrigger + TeamsMessage guidance

Dynamic Teams content can appear inline in the message/body, but the inline AttributeReference shape is different from the structured additionalInformation shape:

  • Inline mixed-content parts in headline / optionalMessage use {"kind":"AttributeReference","type":"complex","arguments":[...]} directly inside the field's values array.

  • Structured entries in additionalInformation use NameReferencePair whose reference argument is {"kind":"AttributeReference","type":"complexReference","name":"reference",...}.

When adding dynamic Teams content to an AttributeTrigger, follow the exact shapes below rather than converting everything to complexReference.

Inline mixed content in optionalMessage

Working readback shape for inline dynamic text in an AttributeTrigger Teams action:

{
  "name": "optionalMessage",
  "type": "array",
  "values": [
    { "name": "string", "type": "string", "value": "The humidity of this package has crossed above or below the allowed range." },
    {
      "kind": "AttributeReference",
      "type": "complex",
      "arguments": [{ "name": "entityId", "type": "string", "value": "<humidity-attr-id>" }]
    },
    { "name": "string", "type": "string", "value": " " }
  ]
}

Use the same mixed-content values array pattern if you need inline dynamic parts in headline.

Combine inline message content and structured additionalInformation like this:

{
  "name": "TeamsBinding",
  "kind": "TeamsMessage",
  "arguments": [
    { "name": "messageLocale", "type": "string", "value": "" },
    { "name": "recipients", "type": "array", "values": [
      { "type": "string", "value": "[email protected]" }
    ]},
    { "name": "headline", "type": "array", "values": [
      { "type": "string", "value": "Building-B critical temperature alert" }
    ]},
    { "name": "optionalMessage", "type": "array", "values": [
      { "name": "string", "type": "string", "value": "The current temperature is " },
      {
        "kind": "AttributeReference",
        "type": "complex",
        "arguments": [{ "name": "entityId", "type": "string", "value": "<temp-attr-id>" }]
      },
      { "name": "string", "type": "string", "value": " and pressure context is included below." }
    ]},
    { "name": "additionalInformation", "type": "array", "values": [
      {
        "kind": "NameReferencePair",
        "type": "complex",
        "arguments": [
          { "name": "name", "type": "string", "value": "Current Temperature" },
          {
            "kind": "AttributeReference",
            "type": "complexReference",
            "name": "reference",
            "arguments": [{ "name": "entityId", "type": "string", "value": "<temp-attr-id>" }]
          }
        ]
      },
      {
        "kind": "NameReferencePair",
        "type": "complex",
        "arguments": [
          { "name": "name", "type": "string", "value": "Current Pressure" },
          {
            "kind": "AttributeReference",
            "type": "complexReference",
            "name": "reference",
            "arguments": [{ "name": "entityId", "type": "string", "value": "<pressure-attr-id>" }]
          }
        ]
      }
    ]}
  ]
}
Structured References in additionalInformation

By attribute entity ID (AttributeReference):

{ "name": "additionalInformation", "type": "array",
  "values": [{
    "kind": "NameReferencePair", "type": "complex",
    "arguments": [
      { "name": "name", "type": "string", "value": "Current Temperature" },
      { "kind": "AttributeReference", "type": "complexReference", "name": "reference",
        "arguments": [{ "name": "entityId", "type": "string", "value": "<attr-id>" }] }
    ] }] }

By raw event field name (EventFieldReference):

{ "kind": "NameReferencePair", "type": "complex",
  "arguments": [
    { "name": "name", "type": "string", "value": "Device ID" },
    { "kind": "EventFieldReference", "type": "complexReference", "name": "reference",
      "arguments": [{ "name": "fieldName", "type": "string", "value": "deviceId" }] }
  ] }

Use EventFieldReference only when the rule template resolves raw event fields directly (commonly EventTrigger). For AttributeTrigger, prefer AttributeReference to the existing attribute entity.

Which Action Fields Accept Enrichments
FieldAccepts
headlineArray of content parts; use strings or mixed string + inline AttributeReference parts (type: "complex")
optionalMessageArray of content parts; use strings or mixed string + inline AttributeReference parts (type: "complex")
subject (EmailMessage only)Static text + AttributeReference
additionalInformationNameReferencePair with AttributeReference; EventFieldReference only when the rule template exposes raw event fields

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.

Security

What our scanner noticed· Low risk

  • Instructions that use the network

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/activator-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.

Download ZIP

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