[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P1BVRK4B0RRCM24A3D086T":3,"skill-same:01M6P1BVRK4B0RRCM24A3D086T":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":13,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6P1BVRK4B0RRCM24A3D086T","data-model",null,"Design a Dataverse data model for a Power Platform solution. Analyze business requirements, propose standard versus custom tables, columns, relationships, N:N relationships, calculated columns, and publisher-prefix naming conventions. Generate a complete schema ready to implement with PAC CLI. Use when the user needs to design tables, a Dataverse schema, an ER model, or decide which entities are needed.","Cesardlcs\u002Fmarketplace_cdlcs","Cesardlcs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6519583?v=4","01M6P1BRGXD40YZM9K0SHG40FZ","01M6P1BRN4ACETK2M2FWBTAQ2V",0,"MIT","https:\u002F\u002Fgithub.com\u002FCesardlcs\u002Fmarketplace_cdlcs\u002Fblob\u002Fmain\u002Fplugins\u002Fdynamics365\u002Fskills\u002Fdata-model\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"model","data model","data","decide","cli","which","tables","github copilot cli","columns","publisher","ready","power","dataverse","design","analyze","projects","github copilot","code","generate","copilot","2026-11-10 10:12:30",false,"---\nname: data-model\ndescription: Design a Dataverse data model for a Power Platform solution. Analyze business requirements, propose standard versus custom tables, columns, relationships, N:N relationships, calculated columns, and publisher-prefix naming conventions. Generate a complete schema ready to implement with PAC CLI. Use when the user needs to design tables, a Dataverse schema, an ER model, or decide which entities are needed.\nlicense: MIT\ncompatibility: Designed for GitHub Copilot CLI or Claude Code in Power Platform \u002F Dataverse development projects. Requires PAC CLI >= 2.3.1.\nmetadata:\n  author: Cdlcs\n  version: \"1.0.0\"\n  argument-hint: \"[business domain or requirement description]\"\n---\n\n# Dataverse Schema Designer\n\n**Triggers**: dataverse-schema, data model, design tables, Dataverse schema, entities, ER diagram\n**Aliases**: \u002Fschema, \u002Fdataverse-schema, \u002Fdata-model\n\n---\n\n## Instructions\n\nFollow these steps in order for every `\u002Fdata-model` invocation.\n\n### Step 1: Verify Environment\n\n```powershell\npac auth list\npac env who\n```\n\nIf there is no authentication, tell the user to run:\n\n```powershell\npac auth create --environment https:\u002F\u002Fyour-env.crm.dynamics.com\n```\n\n### Step 2: Gather Information\n\nUse `AskUserQuestion` to ask the following questions, one by one if they are not already clear from context:\n\n1. **\"What is the business domain?\"** - Briefly describe what the system manages.\n2. **\"What is the publisher prefix?\"** - For example, `src_`. If the user does not know it:\n   ```powershell\n   pac env who --json\n   ```\n3. **\"Are there existing tables to reuse?\"** - Contact, Account, Lead, Opportunity, or custom tables.\n\nIf the user already provided the domain description when invoking `\u002Fdata-model`, use that context directly.\n\n### Step 3: Inspect Existing Tables And Relationships\n\nUse the Dataverse inspection flow that works in this environment instead of relying on `pac modelbuilder list --type entity`.\n\nThis step must always inspect both:\n1. **Column metadata** for each relevant table\n2. **Relationship metadata** for each relevant table\n\nNever assume the absence of a lookup column means there is no relationship. Dataverse relationships can exist as:\n- `N:1` or `1:N` through lookup columns\n- Native `N:N` relationships exposed only through relationship metadata\n\nPrimary inspection flow:\n1. Use the Dataverse table listing capability to discover candidate tables in the environment.\n2. Use table description\u002Fintrospection to inspect each relevant table in detail.\n3. Inspect relationship metadata for the same tables, including `1:N`, `N:1`, and `N:N` relationships.\n4. Inspect both:\n     - Tables explicitly mentioned by the user\n     - Standard tables that might satisfy the requirement without distorting their natural purpose\n\nExpected inspection sequence:\n- List tables in the environment\n- Identify candidate standard tables such as `account`, `contact`, `incident`, `product`, `connection`, `customeraddress`, `msdyn_*`, and relevant custom tables\n- Describe each relevant table to capture:\n    - Existing columns\n    - Data types\n    - Lookups and related tables\n    - Choice values when relevant\n    - Structural fit with the requirement\n- Inspect relationship metadata to capture:\n    - Existing `1:N` relationships\n    - Existing `N:1` relationships\n    - Existing native `N:N` relationships\n    - Relationship schema names when relevant to the recommendation\n\nRequired output from this step:\n- Reused tables that are a good fit\n- Standard tables reviewed but rejected as the primary model\n- Field-level evidence supporting the recommendation\n- Relationship-level evidence supporting the recommendation\n- An explicit statement of whether the recommendation depends on `1:N`, `N:1`, `N:N`, or a new relationship to be created\n\nTooling guidance:\n- Use microsoftdocs-mcp server as one of the resources to get information and design the data model\n- Prefer Dataverse MCP table discovery and table description\u002Fintrospection as the default workflow in this repository\u002Fenvironment\n- When relationship metadata is not visible from table description alone, use `pac modelbuilder build` filtered to the relevant entities to inspect generated relationship constants and `RelationshipSchemaName` attributes\n- Keep `pac auth list` and `pac env who` for environment validation only\n- Do not assume `pac modelbuilder list --type entity` is available\n- Do not conclude that a table is unrelated until relationship metadata has been checked explicitly\n\n### Step 4: Design the Data Model\n\n#### Table Naming\n\n| Type | Example | Rule |\n|------|---------|------|\n| Custom table | `src_work_order` | `{prefix}_{entity_name}` in snake_case |\n| Reused standard table | `account`, `contact` | Original logical name without prefix |\n| N:N relationship | `src_contact_src_project` | `{prefix}_{entity1}_{prefix}_{entity2}` |\n\n#### Column Naming\n\n| Type | Example | Rule |\n|------|---------|------|\n| Custom simple | `src_totalamount` | `{prefix}_{columnname}` in snake_case |\n| Custom lookup | `src_accountid` | `{prefix}_{referencedentity}id` |\n| Reused standard column | `name`, `statuscode` | No prefix |\n\n#### Available Column Types\n\n| Type | When to use |\n|------|-------------|\n| `SingleLine.Text` | Short text (up to 4000 chars) |\n| `MultiLine.Text` | Long text, notes, descriptions |\n| `WholeNumber` | Integers |\n| `Decimal` | Decimal numbers |\n| `Currency` | Monetary values. Prefer Currency over Decimal for money. |\n| `DateTime` | Date and\u002For time |\n| `Boolean` | Yes\u002FNo |\n| `Choice` | Option set. Provide the options. |\n| `Choices` | Multi-select option set |\n| `Lookup` | Foreign key to another table |\n| `Customer` | Special lookup to Account or Contact |\n| `Owner` | Special lookup to User or Team |\n| `Image` | Image |\n| `File` | File attachment |\n| `Uniqueidentifier` | GUID, primary key only |\n\n#### Design Best Practices\n\n1. **Reuse standard tables first**: Account, Contact, Team, User, and others before creating custom tables.\n2. **Primary column**: Always define the primary column name explicitly. The default is usually `name`.\n3. **Status and Status Reason**: Include them when the table has a lifecycle.\n4. **Ownership**: Prefer User-owned unless Organization-owned is clearly better.\n5. **N:N relationships**: Use the native Dataverse intersect relationship when appropriate.\n6. **Virtual Tables**: Use for external data without replication.\n7. **Elastic Tables**: Use for very high-volume telemetry or operational data, typically above 1 million rows per day.\n8. **Calculated columns**: Use for values derived from other columns.\n9. **Rollup columns**: Use for aggregations from child records.\n10. **Propose standard tables only if their original purpose is not distorted.** If the fit is partial, clearly state which existing fields would be reused, which fields would remain unused, which new fields would be required, and how that would affect the natural purpose of the standard table.\n11. **Always evaluate relationships before finalizing the design.** Explicitly account for existing `1:N`, `N:1`, and `N:N` relationships so the recommendation does not miss a native association already present in Dataverse.\n\n### Step 5: Present the Design in Plan Mode\n\nUse `EnterPlanMode` to present the complete design:\n\n```markdown\n## Data Model: [Domain Name]\n\n**Publisher Prefix**: `src_`\n\n### Tables\n\n#### [Table 1: src_work_order] - New\n**Display Name**: Work Order | **Ownership**: User-owned\n\n| Column (Logical Name) | Display Name | Type | Required | Notes |\n|-----------------------|--------------|------|----------|-------|\n| `src_work_orderid` | Work Order | Uniqueidentifier | Yes | PK |\n| `src_name` | Title | SingleLine.Text | Yes | Primary column |\n| `src_description` | Description | MultiLine.Text | No | |\n| `src_status` | Status | Choice | Yes | Options: Open, In Progress, Completed, Cancelled |\n| `src_accountid` | Account | Lookup (account) | No | |\n| `src_totalcost` | Total Cost | Currency | No | |\n| `createdon` | Created On | DateTime | Auto | System field |\n| `ownerid` | Owner | Owner | Auto | System field |\n\n**Relationships**:\n- N:1 with `account` - One account can have many work orders\n\n#### [Table 2: contact] - Reused (standard)\nUsed as-is. Relevant fields: `fullname`, `emailaddress1`, `telephone1`.\n\n### Relationships Reviewed\n\nThis section is **mandatory**. Include both:\n1. Existing relationships actually found (`1:N`, `N:1`, `N:N`)\n2. Rejected conceptual candidates even if no relationship currently exists in metadata\n\nDo not omit N:N relationships.\n\n| Relationship Schema Name | Type | Tables | Decision | Notes |\n|--------------------------|------|--------|----------|-------|\n| `src_account_src_work_order` | 1:N (new) | account → src_work_order | Proposed | Lookup `src_accountid` on new table |\n| `bshcs_incident_bshcs_exampletable` | N:N (existing) | incident ↔ example_table | Reused \u002F Rejected | Reason |\n| `N\u002FA (conceptual candidate)` | Conceptual candidate (not existing relationship) | incident ↔ connection | Rejected | Considered as candidate table option; rejected with rationale |\n| `N\u002FA (conceptual candidate)` | Conceptual candidate (not existing relationship) | incident ↔ customeraddress | Rejected | Considered as candidate table option; rejected with rationale |\n\n> If no native relationship exists between two tables, state that explicitly and still include the conceptual candidate row in this section.\n\n### Rejected Table Options (Fixed Component - Mandatory)\n\nThis section is **mandatory** and must be included in every generated data model output.\n\n| Table Candidate | Why It Looked Viable | Why It Was Rejected For This Case-Subgrid-Driven Process |\n|-----------------|----------------------|-----------------------------------------------------------|\n| `connection` | [Explain initial attractiveness] | [Explain exact process and governance rejection reasons] |\n| `customeraddress` | [Explain initial attractiveness] | [Explain exact process and semantic rejection reasons] |\n\n### Fit\u002FGap Comparison Matrix (Fixed Component - Mandatory)\n\n| Evaluation Criterion | `connection` | `customeraddress` |\n|----------------------|--------------|-------------------|\n| Subgrid creation fit | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Partner-function semantics | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Case-scoped transaction fit | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Alignment with original table purpose | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Operational complexity | [Low\u002FMedium\u002FHigh + short justification] | [Low\u002FMedium\u002FHigh + short justification] |\n\n### Rejection Conclusion (Fixed Component - Mandatory)\n\nProvide a short conclusion that explicitly ties the rejected options back to the selected architecture and business process.\n\n### Why This Architecture Works (Fixed Component - Mandatory)\n\nProvide **strong, multi-dimensional justifications** for the selected architecture design. Cover at least these dimensions:\n\n- **Development & cost efficiency**: Does reusing tables eliminate custom plugins, custom forms, or data migration? Does the design avoid unnecessary complexity?\n- **User experience & process alignment**: Does the architecture match the actual business workflow? Does it leverage built-in Dynamics patterns (subgrid, lookup, choice fields)?\n- **Data integrity & governance**: Does the selected relationship type enforce referential constraints automatically? How does it support audit trails and compliance?\n- **Query, reporting & maintainability**: Are the semantic and business-logic implications clear? Can operations and BI teams write straightforward queries without custom SQL?\n- **Scalability & performance**: Will the design handle the expected data volume without degradation? Are Dataverse native indexing and cardinality appropriate?\n- **Backward compatibility**: Does the design preserve existing data and workflows, or require migration?\n\n**Example structure** (provide 6-8 points like these):\n1. **Eliminates development cost**: Reuses existing table [X] and relationship [Y]—no new plugins or custom forms required.\n2. **Native user experience**: Leverages built-in [subgrid\u002Flookup\u002Fchoice] pattern; no custom apps required.\n3. **Inherent referential integrity**: [Relationship type] enforces required associations automatically.\n4. **Query and reporting simplicity**: [Reason why queries are straightforward and performance optimized].\n5. **Full audit trail compliance**: Standard Dataverse audit logs capture all metadata.\n6. **Backward compatibility**: Existing data continues without migration.\n7. **Simplified semantic model**: [Reason why structure is maintainable and business-clear].\n8. **Scalability and performance**: [Reason native indexing and cardinality handle expected volume].\n\n### ER Diagram\n\n```mermaid\nerDiagram\n    ACCOUNT[\"account (Account)\"] {\n        guid accountid PK\n        string name\n        string emailaddress1\n    }\n    SRC_WORK_ORDER[\"src_work_order (Work Order)\"] {\n        guid src_work_orderid PK\n        guid src_accountid FK\n        string src_name\n        choice src_status\n        decimal src_totalcost\n    }\n    ACCOUNT ||--o{ SRC_WORK_ORDER : \"has\"\n```\n```\n\n### Step 6: Generate Documentation\n\nAfter creating the model, automatically generate:\n1. An ER diagram in Mermaid format.\n2. A `data-model.md` file with the full table and column definition.\n\n### Step 7: Final Summary\n\nProvide:\n- A list of proposed new tables and reused existing tables. Give a brief justification for each reused standard table, explaining how it fits the requirements without distorting its original purpose.\n- **Strong multi-dimensional architectural justifications** (drawn directly from Step 5's \"Why This Architecture Works\" section) covering: development cost\u002Fefficiency, user experience and process alignment, data integrity and governance, query\u002Freporting maintainability, scalability and performance, backward compatibility, and semantic clarity. These arguments must directly address the business context and why alternatives were rejected.\n- Research and validation of the decisions made, especially if proposing reuse of standard tables or native N:N relationships. Consult the microsoftdocs-mcp server and Dataverse relationship metadata to confirm best practices.\n- A relationship summary that explicitly lists the relevant existing `1:N`, `N:1`, and `N:N` relationships reviewed, including relationship schema names when they materially affect the recommendation. Include conceptual rejected candidates even if no current relationship exists.\n- The mandatory fixed components from Step 5 for rejected table options: viability rationale, exact rejection rationale, fit\u002Fgap comparison matrix, and rejection conclusion tied to the selected architecture and business process.\n- The final ER diagram in Mermaid format.","# Dataverse Schema Designer\n\n**Triggers**: dataverse-schema, data model, design tables, Dataverse schema, entities, ER diagram\n**Aliases**: \u002Fschema, \u002Fdataverse-schema, \u002Fdata-model\n\n---\n\n## Instructions\n\nFollow these steps in order for every `\u002Fdata-model` invocation.\n\n### Step 1: Verify Environment\n\n```powershell\npac auth list\npac env who\n```\n\nIf there is no authentication, tell the user to run:\n\n```powershell\npac auth create --environment https:\u002F\u002Fyour-env.crm.dynamics.com\n```\n\n### Step 2: Gather Information\n\nUse `AskUserQuestion` to ask the following questions, one by one if they are not already clear from context:\n\n1. **\"What is the business domain?\"** - Briefly describe what the system manages.\n2. **\"What is the publisher prefix?\"** - For example, `src_`. If the user does not know it:\n   ```powershell\n   pac env who --json\n   ```\n3. **\"Are there existing tables to reuse?\"** - Contact, Account, Lead, Opportunity, or custom tables.\n\nIf the user already provided the domain description when invoking `\u002Fdata-model`, use that context directly.\n\n### Step 3: Inspect Existing Tables And Relationships\n\nUse the Dataverse inspection flow that works in this environment instead of relying on `pac modelbuilder list --type entity`.\n\nThis step must always inspect both:\n1. **Column metadata** for each relevant table\n2. **Relationship metadata** for each relevant table\n\nNever assume the absence of a lookup column means there is no relationship. Dataverse relationships can exist as:\n- `N:1` or `1:N` through lookup columns\n- Native `N:N` relationships exposed only through relationship metadata\n\nPrimary inspection flow:\n1. Use the Dataverse table listing capability to discover candidate tables in the environment.\n2. Use table description\u002Fintrospection to inspect each relevant table in detail.\n3. Inspect relationship metadata for the same tables, including `1:N`, `N:1`, and `N:N` relationships.\n4. Inspect both:\n     - Tables explicitly mentioned by the user\n     - Standard tables that might satisfy the requirement without distorting their natural purpose\n\nExpected inspection sequence:\n- List tables in the environment\n- Identify candidate standard tables such as `account`, `contact`, `incident`, `product`, `connection`, `customeraddress`, `msdyn_*`, and relevant custom tables\n- Describe each relevant table to capture:\n    - Existing columns\n    - Data types\n    - Lookups and related tables\n    - Choice values when relevant\n    - Structural fit with the requirement\n- Inspect relationship metadata to capture:\n    - Existing `1:N` relationships\n    - Existing `N:1` relationships\n    - Existing native `N:N` relationships\n    - Relationship schema names when relevant to the recommendation\n\nRequired output from this step:\n- Reused tables that are a good fit\n- Standard tables reviewed but rejected as the primary model\n- Field-level evidence supporting the recommendation\n- Relationship-level evidence supporting the recommendation\n- An explicit statement of whether the recommendation depends on `1:N`, `N:1`, `N:N`, or a new relationship to be created\n\nTooling guidance:\n- Use microsoftdocs-mcp server as one of the resources to get information and design the data model\n- Prefer Dataverse MCP table discovery and table description\u002Fintrospection as the default workflow in this repository\u002Fenvironment\n- When relationship metadata is not visible from table description alone, use `pac modelbuilder build` filtered to the relevant entities to inspect generated relationship constants and `RelationshipSchemaName` attributes\n- Keep `pac auth list` and `pac env who` for environment validation only\n- Do not assume `pac modelbuilder list --type entity` is available\n- Do not conclude that a table is unrelated until relationship metadata has been checked explicitly\n\n### Step 4: Design the Data Model\n\n#### Table Naming\n\n| Type | Example | Rule |\n|------|---------|------|\n| Custom table | `src_work_order` | `{prefix}_{entity_name}` in snake_case |\n| Reused standard table | `account`, `contact` | Original logical name without prefix |\n| N:N relationship | `src_contact_src_project` | `{prefix}_{entity1}_{prefix}_{entity2}` |\n\n#### Column Naming\n\n| Type | Example | Rule |\n|------|---------|------|\n| Custom simple | `src_totalamount` | `{prefix}_{columnname}` in snake_case |\n| Custom lookup | `src_accountid` | `{prefix}_{referencedentity}id` |\n| Reused standard column | `name`, `statuscode` | No prefix |\n\n#### Available Column Types\n\n| Type | When to use |\n|------|-------------|\n| `SingleLine.Text` | Short text (up to 4000 chars) |\n| `MultiLine.Text` | Long text, notes, descriptions |\n| `WholeNumber` | Integers |\n| `Decimal` | Decimal numbers |\n| `Currency` | Monetary values. Prefer Currency over Decimal for money. |\n| `DateTime` | Date and\u002For time |\n| `Boolean` | Yes\u002FNo |\n| `Choice` | Option set. Provide the options. |\n| `Choices` | Multi-select option set |\n| `Lookup` | Foreign key to another table |\n| `Customer` | Special lookup to Account or Contact |\n| `Owner` | Special lookup to User or Team |\n| `Image` | Image |\n| `File` | File attachment |\n| `Uniqueidentifier` | GUID, primary key only |\n\n#### Design Best Practices\n\n1. **Reuse standard tables first**: Account, Contact, Team, User, and others before creating custom tables.\n2. **Primary column**: Always define the primary column name explicitly. The default is usually `name`.\n3. **Status and Status Reason**: Include them when the table has a lifecycle.\n4. **Ownership**: Prefer User-owned unless Organization-owned is clearly better.\n5. **N:N relationships**: Use the native Dataverse intersect relationship when appropriate.\n6. **Virtual Tables**: Use for external data without replication.\n7. **Elastic Tables**: Use for very high-volume telemetry or operational data, typically above 1 million rows per day.\n8. **Calculated columns**: Use for values derived from other columns.\n9. **Rollup columns**: Use for aggregations from child records.\n10. **Propose standard tables only if their original purpose is not distorted.** If the fit is partial, clearly state which existing fields would be reused, which fields would remain unused, which new fields would be required, and how that would affect the natural purpose of the standard table.\n11. **Always evaluate relationships before finalizing the design.** Explicitly account for existing `1:N`, `N:1`, and `N:N` relationships so the recommendation does not miss a native association already present in Dataverse.\n\n### Step 5: Present the Design in Plan Mode\n\nUse `EnterPlanMode` to present the complete design:\n\n```markdown\n## Data Model: [Domain Name]\n\n**Publisher Prefix**: `src_`\n\n### Tables\n\n#### [Table 1: src_work_order] - New\n**Display Name**: Work Order | **Ownership**: User-owned\n\n| Column (Logical Name) | Display Name | Type | Required | Notes |\n|-----------------------|--------------|------|----------|-------|\n| `src_work_orderid` | Work Order | Uniqueidentifier | Yes | PK |\n| `src_name` | Title | SingleLine.Text | Yes | Primary column |\n| `src_description` | Description | MultiLine.Text | No | |\n| `src_status` | Status | Choice | Yes | Options: Open, In Progress, Completed, Cancelled |\n| `src_accountid` | Account | Lookup (account) | No | |\n| `src_totalcost` | Total Cost | Currency | No | |\n| `createdon` | Created On | DateTime | Auto | System field |\n| `ownerid` | Owner | Owner | Auto | System field |\n\n**Relationships**:\n- N:1 with `account` - One account can have many work orders\n\n#### [Table 2: contact] - Reused (standard)\nUsed as-is. Relevant fields: `fullname`, `emailaddress1`, `telephone1`.\n\n### Relationships Reviewed\n\nThis section is **mandatory**. Include both:\n1. Existing relationships actually found (`1:N`, `N:1`, `N:N`)\n2. Rejected conceptual candidates even if no relationship currently exists in metadata\n\nDo not omit N:N relationships.\n\n| Relationship Schema Name | Type | Tables | Decision | Notes |\n|--------------------------|------|--------|----------|-------|\n| `src_account_src_work_order` | 1:N (new) | account → src_work_order | Proposed | Lookup `src_accountid` on new table |\n| `bshcs_incident_bshcs_exampletable` | N:N (existing) | incident ↔ example_table | Reused \u002F Rejected | Reason |\n| `N\u002FA (conceptual candidate)` | Conceptual candidate (not existing relationship) | incident ↔ connection | Rejected | Considered as candidate table option; rejected with rationale |\n| `N\u002FA (conceptual candidate)` | Conceptual candidate (not existing relationship) | incident ↔ customeraddress | Rejected | Considered as candidate table option; rejected with rationale |\n\n> If no native relationship exists between two tables, state that explicitly and still include the conceptual candidate row in this section.\n\n### Rejected Table Options (Fixed Component - Mandatory)\n\nThis section is **mandatory** and must be included in every generated data model output.\n\n| Table Candidate | Why It Looked Viable | Why It Was Rejected For This Case-Subgrid-Driven Process |\n|-----------------|----------------------|-----------------------------------------------------------|\n| `connection` | [Explain initial attractiveness] | [Explain exact process and governance rejection reasons] |\n| `customeraddress` | [Explain initial attractiveness] | [Explain exact process and semantic rejection reasons] |\n\n### Fit\u002FGap Comparison Matrix (Fixed Component - Mandatory)\n\n| Evaluation Criterion | `connection` | `customeraddress` |\n|----------------------|--------------|-------------------|\n| Subgrid creation fit | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Partner-function semantics | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Case-scoped transaction fit | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Alignment with original table purpose | [Fit\u002FGAP rating + short justification] | [Fit\u002FGAP rating + short justification] |\n| Operational complexity | [Low\u002FMedium\u002FHigh + short justification] | [Low\u002FMedium\u002FHigh + short justification] |\n\n### Rejection Conclusion (Fixed Component - Mandatory)\n\nProvide a short conclusion that explicitly ties the rejected options back to the selected architecture and business process.\n\n### Why This Architecture Works (Fixed Component - Mandatory)\n\nProvide **strong, multi-dimensional justifications** for the selected architecture design. Cover at least these dimensions:\n\n- **Development & cost efficiency**: Does reusing tables eliminate custom plugins, custom forms, or data migration? Does the design avoid unnecessary complexity?\n- **User experience & process alignment**: Does the architecture match the actual business workflow? Does it leverage built-in Dynamics patterns (subgrid, lookup, choice fields)?\n- **Data integrity & governance**: Does the selected relationship type enforce referential constraints automatically? How does it support audit trails and compliance?\n- **Query, reporting & maintainability**: Are the semantic and business-logic implications clear? Can operations and BI teams write straightforward queries without custom SQL?\n- **Scalability & performance**: Will the design handle the expected data volume without degradation? Are Dataverse native indexing and cardinality appropriate?\n- **Backward compatibility**: Does the design preserve existing data and workflows, or require migration?\n\n**Example structure** (provide 6-8 points like these):\n1. **Eliminates development cost**: Reuses existing table [X] and relationship [Y]—no new plugins or custom forms required.\n2. **Native user experience**: Leverages built-in [subgrid\u002Flookup\u002Fchoice] pattern; no custom apps required.\n3. **Inherent referential integrity**: [Relationship type] enforces required associations automatically.\n4. **Query and reporting simplicity**: [Reason why queries are straightforward and performance optimized].\n5. **Full audit trail compliance**: Standard Dataverse audit logs capture all metadata.\n6. **Backward compatibility**: Existing data continues without migration.\n7. **Simplified semantic model**: [Reason why structure is maintainable and business-clear].\n8. **Scalability and performance**: [Reason native indexing and cardinality handle expected volume].\n\n### ER Diagram\n\n```mermaid\nerDiagram\n    ACCOUNT[\"account (Account)\"] {\n        guid accountid PK\n        string name\n        string emailaddress1\n    }\n    SRC_WORK_ORDER[\"src_work_order (Work Order)\"] {\n        guid src_work_orderid PK\n        guid src_accountid FK\n        string src_name\n        choice src_status\n        decimal src_totalcost\n    }\n    ACCOUNT ||--o{ SRC_WORK_ORDER : \"has\"\n```\n```\n\n### Step 6: Generate Documentation\n\nAfter creating the model, automatically generate:\n1. An ER diagram in Mermaid format.\n2. A `data-model.md` file with the full table and column definition.\n\n### Step 7: Final Summary\n\nProvide:\n- A list of proposed new tables and reused existing tables. Give a brief justification for each reused standard table, explaining how it fits the requirements without distorting its original purpose.\n- **Strong multi-dimensional architectural justifications** (drawn directly from Step 5's \"Why This Architecture Works\" section) covering: development cost\u002Fefficiency, user experience and process alignment, data integrity and governance, query\u002Freporting maintainability, scalability and performance, backward compatibility, and semantic clarity. These arguments must directly address the business context and why alternatives were rejected.\n- Research and validation of the decisions made, especially if proposing reuse of standard tables or native N:N relationships. Consult the microsoftdocs-mcp server and Dataverse relationship metadata to confirm best practices.\n- A relationship summary that explicitly lists the relevant existing `1:N`, `N:1`, and `N:N` relationships reviewed, including relationship schema names when they materially affect the recommendation. Include conceptual rejected candidates even if no current relationship exists.\n- The mandatory fixed components from Step 5 for rejected table options: viability rationale, exact rejection rationale, fit\u002Fgap comparison matrix, and rejection conclusion tied to the selected architecture and business process.\n- The final ER diagram in Mermaid format.",{"name":5,"license":14,"metadata":53,"description":7,"compatibility":57},{"author":54,"version":55,"argument-hint":56},"Cdlcs","1.0.0","[business domain or requirement description]","Designed for GitHub Copilot CLI or Claude Code in Power Platform \u002F Dataverse development projects. Requires PAC CLI >= 2.3.1.","main","303a7ce587c6519b50d2d787ebc0492ac4689d00","plugins\u002Fdynamics365\u002Fskills\u002Fdata-model","https:\u002F\u002Fgithub.com\u002FCesardlcs\u002Fmarketplace_cdlcs","https:\u002F\u002Fgithub.com\u002FCesardlcs","2026-04-23 04:05:22",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add Cesardlcs\u002Fmarketplace_cdlcs --skill data-model",{"tool":70,"command":71},"bunx","bunx skills add Cesardlcs\u002Fmarketplace_cdlcs --skill data-model",{"tool":73,"command":74},"pnpm","pnpm dlx skills add Cesardlcs\u002Fmarketplace_cdlcs --skill data-model","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FCesardlcs\u002Fmarketplace_cdlcs\u002Fblob\u002Fmain\u002Fplugins\u002Fdynamics365\u002Fskills\u002Fdata-model\u002FSKILL.md",true,[78,84,88,94],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"output\u002Fdata-model-initial.md","REFERENCE","参考文档",11094,"https:\u002F\u002Fgithub.com\u002FCesardlcs\u002Fmarketplace_cdlcs\u002Fblob\u002Fmain\u002Fplugins\u002Fdynamics365\u002Fskills\u002Fdata-model\u002Foutput\u002Fdata-model-initial.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"output\u002Fpartner-functions.md",7898,"https:\u002F\u002Fgithub.com\u002FCesardlcs\u002Fmarketplace_cdlcs\u002Fblob\u002Fmain\u002Fplugins\u002Fdynamics365\u002Fskills\u002Fdata-model\u002Foutput\u002Fpartner-functions.md",{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"output\u002Fpartner-functions.wiki","OTHER","其他",7448,"https:\u002F\u002Fgithub.com\u002FCesardlcs\u002Fmarketplace_cdlcs\u002Fblob\u002Fmain\u002Fplugins\u002Fdynamics365\u002Fskills\u002Fdata-model\u002Foutput\u002Fpartner-functions.wiki",{"path":95,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":96,"sourceHtmlUrl":97},"output\u002Fsms-logging-analysis.md",8439,"https:\u002F\u002Fgithub.com\u002FCesardlcs\u002Fmarketplace_cdlcs\u002Fblob\u002Fmain\u002Fplugins\u002Fdynamics365\u002Fskills\u002Fdata-model\u002Foutput\u002Fsms-logging-analysis.md",[]]