This skill should be used when the user asks to "create Dataverse tables", "set up the data model", "setup dataverse", "create tables for my site", "setup dataverse schema", "create the database", "build my data model", or wants to create Dataverse tables, columns, and relationships for their Power Pages site based on a data model proposal.
Instrucciones de origen · Vista previa de solo lectura
name
setup-datamodel
description
This skill should be used when the user asks to "create Dataverse tables", "set up the data model", "setup dataverse", "create tables for my site", "setup dataverse schema", "create the database", "build my data model", or wants to create Dataverse tables, columns, and relationships for their Power Pages site based on a data model proposal.
{"Stop":[{"hooks":[{"type":"command","command":"node \"${CLAUDE_PLUGIN_ROOT}/skills/setup-datamodel/scripts/validate-datamodel.js\"","timeout":30},{"type":"prompt","prompt":"If a Dataverse data model was being set up in this session (via /power-pages:setup-datamodel), verify before allowing stop: 1) A data model was obtained (either the data-model-architect agent was invoked OR the user uploaded an existing ER diagram that was parsed), 2) The user approved the proposal, 3) All approved tables were created, 4) A summary was presented. If incomplete, return { \"ok\": false, \"reason\": \"<specific issues>\" }. Otherwise return { \"ok\": true }.\n","timeout":30}]}]}
Set Up Dataverse Data Model
Guide the user through creating Dataverse tables, columns, and relationships for their Power Pages site. Follow a systematic approach: verify prerequisites, obtain a data model (via AI analysis or user-provided diagram), review and approve, then create all schema objects via OData API.
Core Principles
Never create without approval: Always present the full data model proposal and get explicit user confirmation before making any Dataverse changes.
Use TaskCreate/TaskUpdate: Track all progress throughout all phases — create the todo list upfront with all phases before starting any work.
Resilient execution: Refresh tokens proactively, check for existing tables before creating, and report failures without automated rollback.
Initial request: $ARGUMENTS
Phase 1: Verify Prerequisites
Goal: Confirm PAC CLI authentication, acquire an Azure CLI token, and verify API access
Follow the prerequisite steps in ${CLAUDE_PLUGIN_ROOT}/references/dataverse-prerequisites.md to verify PAC CLI auth, acquire an Azure CLI token, and confirm API access. Store the environment URL as $envUrl.
Relationship definitions: type (1:N or M:N), referenced/referencing tables
Query existing Dataverse tables (same as Phase 3 would) to mark each table as new, modified, or reused.
Generate a Mermaid ER diagram from the parsed data (if the user provided an image or text) for visual confirmation.
Proceed directly to Phase 4: Review Proposal with the parsed data model.
Path B: Let the Data Model Architect Figure It Out
If the user chooses to let the Data Model Architect figure it out, proceed to Phase 3: Invoke Data Model Architect (the existing automated flow).
Output: Data model source chosen and, for Path A, parsed data model ready for review
Phase 3: Invoke Data Model Architect
Goal: Spawn the data-model-architect agent to autonomously analyze the site and propose a data model
Actions:
Use the Task tool to spawn the data-model-architect agent. This agent autonomously:
Analyzes the site's source code to infer data requirements
Queries existing Dataverse tables via OData GET requests
Identifies reuse opportunities (reuse, extend, or create new)
Proposes a complete data model with an ER diagram
Spawn the agent:
Task tool:
subagent_type: general-purpose
prompt: |
You are the data-model-architect agent. Follow the instructions in
the agent definition file at:
${CLAUDE_PLUGIN_ROOT}/agents/data-model-architect.md
Analyze the current project and Dataverse environment, then propose
a complete data model. Return:
1. Publisher prefix
2. Table definitions (logicalName, displayName, status, columns, relationships)
3. Mermaid ER diagram
Wait for the agent to return its structured proposal before proceeding.
Output: Structured data model proposal from the agent (publisher prefix, table definitions, ER diagram)
Phase 4: Review Proposal
Goal: Present the data model proposal to the user and get explicit approval before creating anything
Actions:
4.1 Present Proposal
Present the data model proposal directly to the user as a formatted message, including:
Publisher prefix
All proposed tables with columns (logical names + display names)
Relationship descriptions
Mermaid ER diagram
Which tables are new vs. modified vs. reused
4.2 Get User Approval
Use AskUserQuestion to get approval:
Question
Header
Options
Does this data model look correct?
Data Model Proposal
Approve and create tables (Recommended), Request changes, Cancel
If "Approve and create tables (Recommended)": Proceed to Phase 5
If "Request changes": Ask what they want changed, modify the proposal, and re-present for approval
If "Cancel": Stop the skill
Only proceed to creation after explicit user approval.
Output: User-approved data model proposal
Phase 5: Pre-Creation Checks
Goal: Refresh the token, verify what already exists in Dataverse, and build the creation plan to avoid duplicates
Actions:
5.1 Refresh Token
Re-acquire the Azure CLI token (tokens expire after ~60 minutes):
If 404: Table does not exist, proceed to create it
If 200: Table already exists — skip creation, warn the user
For tables marked as modified, verify the table exists (it should) and check which columns are missing.
5.3 Build Creation Plan
From the pre-creation checks, build a list of:
Tables to create (new tables that don't exist yet)
Columns to add (new columns on existing/modified tables)
Relationships to create
Tables/columns to skip (already exist)
Inform the user of any skipped items.
Output: Finalized creation plan with tables, columns, and relationships to create or skip
Phase 6: Create Tables & Columns
Goal: Create each approved table and its columns using the Dataverse OData Web API
Actions:
Refer to references/odata-api-patterns.md for full JSON body templates.
6.1 Create Tables
For each new table, POST to the EntityDefinitions endpoint:
$body = <JSON body from references/odata-api-patterns.md>
$headers = @{
Authorization = "Bearer $token"
"Content-Type" = "application/json"
Accept = "application/json"
}
Invoke-RestMethod -Method Post -Uri "$envUrl/api/data/v9.2/EntityDefinitions" -Headers $headers -Body $body
Use the deep-insert pattern to create the table and its columns in a single POST request. See references/odata-api-patterns.md for the complete JSON structure.
6.2 Add Columns to Existing Tables
For tables marked as modified, add new columns one at a time:
$body = <column JSON from references/odata-api-patterns.md>
Invoke-RestMethod -Method Post -Uri "$envUrl/api/data/v9.2/EntityDefinitions(LogicalName='<table>')/Attributes" -Headers $headers -Body $body
6.3 Track Progress
Track each creation attempt and its result (success/failure/skipped). Do NOT attempt automated rollback on failure — report failures and continue with remaining items.
6.4 Refresh Token if Needed
If creating many tables, refresh the token between batches (every 3–4 tables) to avoid expiration:
After successful verification, write .datamodel-manifest.json to the project root. This file records which tables and columns were verified to exist, and is used by the validation hook.
Use the Write tool to create this file at <PROJECT_ROOT>/.datamodel-manifest.json. Only include tables and columns that were confirmed to exist in Step 8.2. See ${CLAUDE_PLUGIN_ROOT}/references/datamodel-manifest-schema.md for the full schema specification.
Mark each task in_progress when starting it and completed when done via TaskUpdate. This gives the user visibility into progress and keeps the workflow deterministic.
