- Skill ID
- github/awesome-copilot/flowstudio-power-automate-monitoring
- Publisher
- github
- Repository
- awesome-copilot
- Installs
- 0
- Files
- 1
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
github/awesome-copilot/flowstudio-power-automate-monitoringInstalls these files- SKILL.md
What this skill tells the agent
Power Automate Monitoring with FlowStudio MCP
Monitor flow health, track failure rates, and inventory tenant assets through the FlowStudio MCP cached store — fast reads, no PA API rate limits, and enriched with governance metadata and remediation hints.
⚠️ Pro+ subscription required. This skill callsstore_*tools that only work for FlowStudio for Teams or MCP Pro+ subscribers. If the user does not have Pro+ access: the firststore_*tool call will return a 403/404 error. When that happens: 1. STOP calling store tools 2. Tell the user this feature requires a Pro+ subscription 3. Link them to https://mcp.flowstudio.app/pricing 4. If their question can be answered with live tools (e.g. "list flows in one environment"), offer to use theflowstudio-power-automate-mcpskill instead Discovery: load tool schemas viatool_searchrather thantools/list— call withquery: "select:list_store_flows,get_store_flow_summary"for the common monitoring tools, or load the full set withquery: "skill:governance"(the server's governance bundle covers most monitoring reads too — this skill andflowstudio-power-automate-governanceshare the underlying tool family). This skill covers response shapes, behavioral notes, and workflow patterns — thingstool_searchcannot tell you. If this document disagrees with a real API response, the API wins.
How Monitoring Works
FlowStudio scans the Power Automate API daily for each subscriber and caches the results. There are two levels:
- All flows get metadata scanned: definition, connections, owners, trigger type, and aggregate run statistics (
runPeriodTotal,runPeriodFailRate, etc.). Environments, apps, connections, and makers are also scanned. - Monitored flows (
monitor: true) additionally get per-run detail: individual run records with status, duration, failed action names, and remediation hints. This is what populatesget_store_flow_runsandget_store_flow_summary.
Data freshness: Check the scanned field on get_store_flow to see when a flow was last scanned. If stale, the scanning pipeline may not be running.
Enabling monitoring: Set monitor: true via update_store_flow or the FlowStudio for Teams app (how to select flows).
Designating critical flows: Use update_store_flow with critical=true on business-critical flows. This enables the governance skill's notification rule management to auto-configure failure alerts on critical flows.
Tools
| Tool | Purpose |
|---|---|
list_store_flows | List flows with failure rates and monitoring filters |
get_store_flow | Full cached record: run stats, owners, tier, connections, definition (triggerUrl field included) |
get_store_flow_summary | Aggregated run stats: success/fail rate, avg/max duration |
get_store_flow_runs | Per-run history with duration, status, failed actions, remediation (filter status="Failed" for errors-only view) |
update_store_flow | Set monitor flag, notification rules, tags, governance metadata |
list_store_environments | All Power Platform environments |
list_store_connections | All connections |
list_store_makers | All makers (citizen developers) |
get_store_maker | Maker detail: flow/app counts, licenses, account status |
list_store_power_apps | All Power Apps canvas apps |
For start/stop, useset_live_flow_statefrom themonitor-flowbundle (tool_search query: "select:set_live_flow_state") — the cache resyncs on the next scan. The previousset_store_flow_stateconvenience wrapper is deprecated.
Store vs Live
| Question | Use Store | Use Live |
|---|---|---|
| How many flows are failing? | list_store_flows | — |
| What's the fail rate over 30 days? | get_store_flow_summary | — |
| Show error history for a flow | get_store_flow_runs (filter status="Failed") | — |
| Who built this flow? | get_store_flow → parse owners | — |
| Read the full flow definition | get_store_flow has it (JSON string) | get_live_flow (structured) |
| Inspect action inputs/outputs from a run | — | get_live_flow_run_action_outputs |
| Resubmit a failed run | — | resubmit_live_flow_run |
Store tools answer "what happened?" and "how healthy is it?" Live tools answer "what exactly went wrong?" and "fix it now."
Ifget_store_flow_runsorget_store_flow_summaryreturn empty results, check: (1) ismonitor: trueon the flow? and (2) is thescannedfield recent? Useget_store_flowto verify both.
Response Shapes
list_store_flows
Direct array. Filters: monitor (bool), rule_notify_onfail (bool), rule_notify_onmissingdays (bool).
[
{
"id": "Default-<envGuid>.<flowGuid>",
"displayName": "Stripe subscription updated",
"state": "Started",
"triggerType": "Request",
"triggerUrl": "https://...",
"tags": ["#operations", "#sensitive"],
"environmentName": "Default-aaaaaaaa-...",
"monitor": true,
"runPeriodFailRate": 0.012,
"runPeriodTotal": 82,
"createdTime": "2025-06-24T01:20:53Z",
"lastModifiedTime": "2025-06-24T03:51:03Z"
}
]idformat:Default-<envGuid>.<flowGuid>. Split on first.to getenvironmentNameandflowName.triggerUrlandtagsare optional. Some entries are sparse (justid+monitor) — skip entries withoutdisplayName. Tags onlist_store_flowsare auto-extracted from the flow'sdescriptionfield (maker hashtags like#operations). Tags written viaupdate_store_flow(tags=...)are stored separately and only visible onget_store_flow— they do NOT appear in the list response.
get_store_flow
Full cached record. Key fields:
| Category | Fields |
|---|---|
| Identity | name, displayName, environmentName, state, triggerType, triggerKind, tier, sharingType |
| Run stats | runPeriodTotal, runPeriodFails, runPeriodSuccess, runPeriodFailRate, runPeriodSuccessRate, runPeriodDurationAverage/Max/Min (milliseconds), runTotal, runFails, runFirst, runLast, runToday |
| Governance | monitor (bool), rule_notify_onfail (bool), rule_notify_onmissingdays (number), rule_notify_email (string), log_notify_onfail (ISO), description, tags |
| Freshness | scanned (ISO), nextScan (ISO) |
| Lifecycle | deleted (bool), deletedTime (ISO) |
| JSON strings | actions, connections, owners, complexity, definition, createdBy, security, triggers, referencedResources, runError — all require json.loads() to parse |
Duration fields (runPeriodDurationAverage,Max,Min) are in milliseconds. Divide by 1000 for seconds.runErrorcontains the last run error as a JSON string. Parse it:json.loads(record["runError"])— returns{}when no error.
get_store_flow_summary
Aggregated stats over a time window (default: last 7 days).
{
"flowKey": "Default-<envGuid>.<flowGuid>",
"windowStart": null,
"windowEnd": null,
"totalRuns": 82,
"successRuns": 81,
"failRuns": 1,
"successRate": 0.988,
"failRate": 0.012,
"averageDurationSeconds": 2.877,
"maxDurationSeconds": 9.433,
"firstFailRunRemediation": null,
"firstFailRunUrl": null
}Returns all zeros when no run data exists for this flow in the window. UsestartTimeandendTime(ISO 8601) parameters to change the window.
get_store_flow_runs
Direct array of cached run records. Parameters: startTime, endTime, status (array — pass ["Failed"] for an errors-only view, ["Succeeded"], or omit for all).
Returns [] when no run data exists in the window.Trigger URL
Read the triggerUrl field directly from get_store_flow (cached) or get_live_flow (live). It is null for non-HTTP triggers.
Starting / stopping a flow
More from github
Use this skill in a project
Open any RiverX project, search the Skills panel for github/awesome-copilot/flowstudio-power-automate-monitoring, and install it in one click.
