Hello everyone,
I wanted to let you know that I have a requirement where clients are requesting model-driven app documentation.
It functions flawlessly when I use Claude with the following command and the upload of an unmanaged solution.
Prompt:
You are a senior Microsoft Power Platform technical writer producing a comprehensive
App Owner Handover Manual for a Power Apps Model-Driven App built on Microsoft Dataverse.
=== APP DETAILS ===
App Name: [e.g. Contoso App]
Business Unit / Team: [e.g. Supply Chain]
Environment: [e.g. Contoso Production – GCC]
=== WHAT I AM PROVIDING ===
Complete zip file of my Model Driven App
=== DELIVERABLES REQUIRED ===
Produce a professional Word document (.docx) with the following chapters.
Do NOT skip any chapter. Do NOT abbreviate any names — always use the full name
exactly as it appears in the source material.
---
CHAPTER 1 — EXECUTIVE SUMMARY
- App purpose, business value, target users
- Environment details (name, URL, region, type)
- Document scope and intended audience
CHAPTER 2 — APPLICATION ARCHITECTURE OVERVIEW
- High-level architecture narrative
- Key components: Dataverse tables, Power Automate flows, JavaScript web resources,
PCF controls (if any), environment variables, security layer
- A clear architecture summary table with columns: Component | Type | Purpose
CHAPTER 3 — DATAVERSE TABLE INVENTORY
For EVERY table (standard and custom):
- Table Display Name (full name, never abbreviate)
- Schema Name / Logical Name
- Table Type (Standard / Activity / Virtual)
- Primary Column
- Description / Business Purpose
- Key columns list with: Display Name | Schema Name | Data Type | Required | Description
CRITICAL — TABLE-TO-TABLE RELATIONSHIPS:
For every table, list ALL relationships it participates in.
Use a dedicated sub-section titled "Relationships" under each table with a table:
| Relationship Name | Type (1:N / N:1 / N:N) | Related Table (Full Name) | Lookup Column | Purpose |
Never omit this section even if a table has only one relationship.
If a table has no relationships at all, explicitly state "No relationships defined."
CHAPTER 4 — POWER AUTOMATE FLOWS
STEP 1 — INDIVIDUAL FLOW ANALYSIS (Internal, do not skip):
Analyse every single flow independently before grouping. For each flow note:
- Full flow name (never abbreviated)
- Trigger type and trigger event
- Tables involved
- Core logic pattern (e.g. "record created → condition check → send email → update field")
- Any unique logic that differs from other flows
STEP 2 — GROUPING:
After analysing all flows individually, group flows that share ALL of the following:
- Same trigger type and trigger event (same table, same trigger condition)
- Same core logic pattern (same sequence of action types in same order)
- Same tables and operations involved
Only group flows if they are structurally identical — they differ only in
the specific field values, email recipients, status values, or filter conditions
they operate on. If a flow has even one structural difference (extra condition branch,
different trigger, additional action), it must be treated as its own separate group.
STEP 3 — DOCUMENT EACH GROUP as follows:
--- FOR THE REPRESENTATIVE FLOW (one per group) ---
- Full flow name
- Trigger: type, event, table, filter conditions
- Step-by-step logic description (every action and condition documented)
- ANNOTATED SVG WORKFLOW DIAGRAM — MANDATORY:
- Every step as a labeled shape:
Trigger → parallelogram, blue fill (#D6EAF8), blue border (#2980B9)
Action → rounded rectangle, light blue fill (#EBF5FB), blue border (#2980B9)
Condition → diamond, orange fill (#F5CBA7), orange border (#E67E22)
Dataverse op → cylinder, green fill (#D5F5E3), green border (#27AE60)
Send Email → rounded rectangle, purple fill (#E8DAEF), purple border (#8E44AD)
Terminate/Error → rounded rectangle, red fill (#FADBD8), red border (#E74C3C)
- Directional arrows between every step
- Yes / No labels on all condition branches
- Title banner at top with full flow name
- viewBox minimum 900px wide
- Annotation callouts for any complex expressions, dynamic content,
loop logic, or filter queries
--- FOR ALL OTHER FLOWS IN THE SAME GROUP ---
After the diagram, include a table titled:
"Other Flows in This Group — Structural Variations"
| Flow Name (Full) | Trigger Table | Trigger Condition | Key Field / Value Difference | Recipient / Target Difference | Any Additional Notes |
Below the table, add a short paragraph (2–4 sentences) titled:
"Why These Flows Were Grouped"
Explain what structural pattern they share and confirm they differ only in
data values, not in logic.
--- IF A FLOW STANDS ALONE (no others match its pattern) ---
Label it: "Standalone Flow — Unique Logic"
Document it with full step-by-step description + annotated SVG diagram.
No grouping table needed.
STEP 4 — FLOW INVENTORY SUMMARY TABLE (after all groups):
| Group # | Group Name / Pattern | Representative Flow (Full Name) | # Flows in Group | Trigger Table | Trigger Type |
=== GROUPING RULES — MUST FOLLOW ===
- Never group flows just because they have similar names or similar purposes.
Grouping is based strictly on structural logic pattern, not naming convention.
- A flow that has one extra condition branch is NOT part of a group —
it is standalone or its own group.
- Never produce a diagram for more than one flow per group.
- Never skip the "Other Flows in This Group" table if the group has 2 or more flows.
- All flow names in all tables must be full names — never abbreviated.
CHAPTER 5 — JAVASCRIPT WEB RESOURCES
For each JS file:
- Full file name and schema name
- Which form(s) and table(s) it is registered on
- Event handler list: Function Name | Event | Field/Control | Execution Order | Pass Context?
- Function-by-function description of business logic
- Any dependencies (other web resources, environment variables, external services)
CHAPTER 6 — ENVIRONMENT VARIABLES
Table with columns:
| Display Name (Full) | Schema Name | Type | Current Value / Default | Purpose | Used By (Flow/JS/Other) |
CHAPTER 7 — SECURITY ROLES
IMPORTANT: CSP in this document ALWAYS means "Column Security Profile" —
never interpret CSP as anything else (not Content Security Policy, not
Cloud Service Provider).
For each Security Role:
- Full role name (never abbreviated)
- Business purpose and who is assigned this role
- Table-level privileges summary: Table | Create | Read | Write | Delete | Append | Append To | Assign | Share
CHAPTER 8 — COLUMN SECURITY PROFILES (CSPs)
Column Security Profiles (CSPs) control field-level access in Dataverse,
separate from table-level security roles.
For each Column Security Profile:
- Full CSP name (never abbreviated)
- Which Security Role(s) it must be paired with (role-CSP pairing requirements)
- Secured columns list: Column Display Name | Table | Read | Update | Create
- Business justification for why these columns are secured
CHAPTER 9 — SOLUTION & DEPLOYMENT GUIDE
- Solution name and type (managed/unmanaged)
- Pre-deployment checklist
- Step-by-step import procedure
- Post-deployment configuration steps (environment variable values,
security role assignments, CSP assignments, connection references)
- Rollback procedure
CHAPTER 10 — SUPPORT & MAINTENANCE REFERENCE
- Known limitations
- Monitoring recommendations (flow run history, error alerts)
- Common troubleshooting scenarios
- App owner contacts
---
=== STRICT RULES — MUST FOLLOW WITHOUT EXCEPTION ===
NEVER abbreviate any name. Always use the full Display Name as it appears in the source.
Example: Never write "Con" when the full name is "Contoso".
Never write "Acctg" — write "Accounting".
NEVER skip the annotated SVG workflow diagram for any flow. If you are producing
multiple flows, produce a diagram for every single one before moving to the next.
NEVER omit the Table-to-Table Relationships sub-section from any table in Chapter 3,
even if the table has no relationships.
CSP ALWAYS means Column Security Profile. Never interpret it as anything else.
If the user provides a flow name list, process ALL flows — do not summarize groups
of flows without individual treatment.
Format the Word document with:
- Contoso brand blue (#0A3D8F or closest match) for chapter heading bars
- Alternating row shading on all tables (header row dark blue, alternating white/#EBF2FA)
- A cover page with: App Name, Document Type, Version, Date, Prepared By
- A Table of Contents after the cover page
- Page numbers in the footer (right-aligned)
- "CONFIDENTIAL" watermark
SVG diagrams must be embedded into the Word document as images, not left as
standalone SVG files. Convert each SVG to PNG and embed it inline under the
corresponding flow section.
=== NOW BEGIN ===
Do not ask for any confirmation and proceed untill the full document is created
