---
name: review-component
description: Structured review for complex existing Dataverse components (flows, plugins, forms, solutions). Handles large responses with phased parsing — metadata first, then structure, then targeted deep-dive. Use when reviewing an existing complex component or when tool responses are too large to parse effectively.
argument-hint: "[environment-name] [component-type] [component-identifier]"
---

# Review Dataverse Component

Structured, phased review for complex existing components. Solves the "massive tool response" problem by parsing in stages rather than attempting to digest everything at once.

## Arguments

- `$ARGUMENTS[0]` — Dataverse environment name
- `$ARGUMENTS[1]` — Component type: `flow`, `plugin`, `form`, `solution`, `view`, `web-resource`
- `$ARGUMENTS[2]` — Component identifier (name, GUID, or logical name)

## When to Use

- Reviewing a flow with 10+ actions
- Reviewing a plugin assembly with multiple steps
- Reviewing a form with many tabs/sections/fields/events
- Reviewing a solution's component manifest before import
- Any time a tool response is too large to parse in one pass
- When you need to understand upstream/downstream impact of a change

## Phase 1: Metadata

Get the component's identity and high-level state. Do NOT retrieve the full definition yet.

**For flows:**
```
dataverse_get_flow(flow_id) — OR — dataverse_list_flows and filter by name
```
Capture: name, state (active/draft), owner, solution, created/modified dates

**For plugins:**
```
dataverse_list_plugin_assemblies — filter by name
dataverse_list_plugin_steps(assembly_id)
```
Capture: assembly name, version, step count, registered messages

**For forms:**
```
dataverse_list_forms(table_name, type_filter: "main") — find the form
```
Capture: form name, form ID, type, state, table

**For solutions:**
```
dataverse_get_solution(solution_name)
```
Capture: solution name, version, publisher, managed/unmanaged

## Phase 2: Parse Structure

Now retrieve the full definition and parse it into sections. Do NOT try to understand every detail — just map the structure.

**For flows — parse the clientdata/definition:**
1. **Trigger:** type (automated/manual/scheduled), table, filter conditions
2. **Actions (count + names):** list each action by name and type (Compose, Condition, HTTP, Dataverse action, etc.)
3. **Branching:** identify Condition actions and their yes/no paths
4. **Error handling:** identify Scope actions with runAfter configured for failure
5. **Connection references:** which connectors does this flow use?

Present as a numbered action list:
```
Trigger: When a record is created (account)
1. Get_Account_Details (Dataverse - Get Row)
2. Check_Status (Condition)
   2a. [Yes] Send_Notification (Office 365 - Send Email)
   2b. [No] Update_Record (Dataverse - Update Row)
3. Log_Completion (Compose)
```

**For plugins — parse the step registrations:**
```
Assembly: ContosPlugins.dll (v1.0.0)
Steps:
1. PreValidation / Create / account → AccountCreateValidator
2. PostOperation / Update / contact (filtering: firstname, lastname) → ContactUpdateHandler
3. PostOperation / Delete / opportunity → OpportunityDeleteCleanup
```

**For forms — parse the formxml:**
```
Form: Main Form (account)
Tabs:
1. General (3 sections)
   - Section 1: name, accountnumber, telephone1
   - Section 2: primarycontactid, websiteurl
   - Section 3: [Subgrid: Active Contacts]
2. Details (2 sections)
   - Section 1: description, revenue
   - Section 2: [Web Resource: account_scripts.js]
Events: OnLoad (account_scripts.js::Contoso.Account.onLoad)
```

**For solutions — parse the component manifest:**
```
Solution: ContosoApp (v1.2.0, Unmanaged)
Components:
- Tables: 5 (account, contact, contoso_project, contoso_task, contoso_milestone)
- Forms: 8
- Views: 12
- Flows: 3
- Web Resources: 4
- Security Roles: 2
- Sitemap: 1
```

## Phase 3: Summarize

Present the structural overview to the user. Ask: "What aspect of this component do you want to focus on?" or proceed to the relevant section if the task is already clear.

## Phase 4: Targeted Deep-Dive

Based on the current task, dive into ONLY the relevant sections:
- If fixing a flow trigger: read trigger config in detail, skip actions
- If reviewing form layout: read tab/section structure, skip events
- If assessing plugin impact: focus on filtering attributes and message types
- If evaluating solution for import: focus on components that will overwrite (sitemaps, security roles, forms)

## Phase 5: Impact Assessment

Map what depends on this component and what it depends on:

**Upstream (what feeds into this component):**
- What triggers it? (table changes, manual invocation, schedule)
- What data does it read? (which tables, columns, relationships)

**Downstream (what this component affects):**
- What does it create/update/delete?
- What other components reference this one?
- If this component were changed, what else would break?

Present as a dependency map.

## Guardrails

- **Never propose changes to a component you haven't fully parsed through Phase 2.** Understanding structure is mandatory before suggesting modifications.
- **For flows:** always identify connection references before suggesting changes — changing a connector action may require a different connection ref.
- **For plugins:** always check filtering attributes — a change to step filtering can cause the plugin to fire (or stop firing) on different operations.
- **For solutions:** always check for sitemap and security role components before recommending import — these are the highest-risk overwrite targets.

## Validation

After completing a review:
- Confirm the structural summary is accurate (spot-check 2-3 items against the raw definition)
- Report: component type, name, structural summary, key findings, dependencies identified, recommended next steps