manage-flows

Flow Lifecycle Manager

Autonomous agent for flow lifecycle operations: publish-and-test, batch operations, inventory reports.

Tools

This skill uses the FlowAgent MCP tools, referred to by bare name (clients surface them as mcp__flowagent__<tool> in Claude Code or flowagent-<tool> in Copilot CLI). Use CLI shell commands (local engine build only) for CLI-only operations (connection lifecycle, sharing, solutions/admin) or when no MCP tools are present.

Capabilities

1. Publish-and-Test Cycle

1. Call publish_flow to enable
2. Call run_flow with wait: true and timeout: 30 to trigger and wait for completion
3. Report: pass/fail, duration, action statuses

2. Batch Operations

For multiple flows (IDs from $ARGUMENTS or from list_flows):

• Batch disable: Call disable_flow per flow
• Batch delete: First list the exact flows (name + ID) to the user and get explicit confirmation. Never delete "all flows" in an environment from a single instruction. Then call delete_flow per flow. After 3 deletes in 10 minutes the server returns BulkDeleteConfirmRequired; pass confirmBulk: true only for flows the user has confirmed. Deleted flows can be recovered with list_backups / restore_backup.
• Batch publish: Call publish_flow per flow Report per-item success/failure.

3. Inventory Report

1. Call list_environments to get environments. Large tenants return a partial page (total, nextSkip, note) - page with skip or filter with query; never treat a partial page as the full list. Reuse this discovery across the per-environment loop rather than listing environments again for every flow lookup. Metadata is cached in memory for up to 60 seconds; use fresh: true for explicitly requested current discovery, then page without repeating the fresh bypass
2. Call list_flows on each environment (or only the ones the user specified) - do not stop at the current one. A partial response contains flows, complete: false and nextCursor: continue with cursor: nextCursor and unchanged env, top, name and filter. Follow all cursors before treating an environment's count as complete. Continuations may reuse one metadata page for up to 60 seconds; start without a cursor for fresh data. If a changed page requires restarting, discard earlier partial counts for that environment. For many environments, cap the loop (e.g. the first 10-20, or those the user names), and keep going past individual failures. A large tenant is a reason to cap, never a reason to inventory only one: unless the user scoped it, cover at least the first 10 environments before reporting, then offer to continue
3. Produce summary: flow counts by state, trigger types, recent modifications
4. State coverage explicitly: "N of M environments inventoried" and list any skipped, failed or still-partial environments. Count an environment as fully inventoried only when its flow cursors are exhausted. If only one was inventoried (user scoped it, or others failed), say so rather than presenting it as the full tenant

4. Health Check

For each flow in an environment:

1. Call get_run_history with top: 5
2. Count Succeeded vs Failed runs
3. Flag flows with >50% failure rate Report: flow name, success rate, last run status, last failure error.

5. Incident Response (runaway runs)

When a flow is misfiring with many queued runs:

1. Call cancel_all_runs to bulk-cancel every Running/Waiting run (uses the Dataverse bulk action for solution & modern non-solution flows, per-run fallback otherwise). Pass turnOff: true to also disable the flow while the root cause is fixed.
2. After fixing, resubmit_run the affected runs (note: only self-invoked runs are resubmittable per PA policy).