githubcopilot-power-platform-architect

name	githubcopilot-power-platform-architect
description	Use this skill when the user needs to transform business requirements, use case descriptions, or meeting transcripts into a technical Power Platform solution architecture, including component selection and Mermaid.js diagrams.
license	MIT
metadata	{"author":"Tim Hanewich"}

Power Platform Architect Skill

Context

This skill acts as a Senior Solution Architect specialized in the Microsoft Power Platform ecosystem (Power Apps, Power Automate, Power BI, Power Pages, Copilot Studio, and others). It excels at extracting technical requirements from unstructured data like meeting transcripts or high-level use case descriptions.

Example Trigger Phrases

• "Review this transcript from our discovery session and tell me how to build it."
• "What Power Platform components should I use for this HR onboarding use case?"
• "Generate an architecture diagram for a Power Apps solution that connects to SQL and uses an approval flow."

Power Platform Component Catalog

The Power Platform provides a vast suite of tools that can be used in any digital solution. Below is a list of the various components (at least the main ones) that may be involved in your output architecture.

• Power Apps:- Custom business apps (Canvas or Model-Driven) for task-specific or data-centric interfaces for internal users:
  • Canvas Apps: Best for quickly standing up business apps using interactive drag-and-drop tools while retaining full control over the interface layout and behavior. Use this when you want rapid development with a visual designer, need to connect to multiple diverse data sources, or want a pixel-perfect mobile or tablet experience without writing code (e.g., a frontline worker mobile app or a field inspection form).
  • Model-Driven Apps: Best for data-dense, process-heavy "back-office" applications. These are automatically generated from your Dataverse schema. Use this when you need a standardized responsive design and complex security/relationship management (e.g., a CRM or Asset Management system).
    • Code Apps: Best for full control using code-first frameworks (React) in an IDE like VS Code, while still leveraging Power Platform's managed hosting, Entra ID authentication, 1,500+ connectors callable from JavaScript, and governance (DLP, Conditional Access, sharing limits). Use this when the app demands a custom front-end beyond what Canvas or Model-Driven can offer but still needs to run on the managed platform.
• Power Pages:- Secure, low-code websites for external partners, customers, or internal portals.
• Copilot Studio:- AI-powered conversational agents for natural language interaction with users and data. Build agents that can leverage knowledge sources to provide grounded answers, use tools to take action against systems, and work autonomously (background).
• Power Automate:- Automation platform spanning cloud and desktop:
  • Digital Process Automation (Cloud Flows): Cloud-based workflows triggered in three ways — Scheduled (run on a recurring timer, e.g., nightly data sync), Instant (manually triggered by a user button press or app action), or Automated (fired by an event such as a new record created, an email received, or a form submitted). Use for cross-system integration, approval workflows, and business process orchestration.
  • Robotic Process Automation (Desktop Flows): UI-based automation that mimics human interaction with desktop applications and legacy systems. Use when there is no API available and you need to automate clicks, keystrokes, and screen scraping on older or on-premises software (e.g., mainframe terminals, legacy ERP clients).
• AI Builder:- Pre-built AI models (OCR, sentiment analysis, prediction) to add intelligence to processes. AI Builder has the following AI models available:
  • Prompts:- Custom generative AI instructions for standardized LLM-based interactions.
  • Document processing (Custom): Extracts specific, user-defined information from complex or unstructured documents.
  • Invoice processing (Prebuilt): Pulls key data points like vendor, date, and totals from standard invoices.
  • Text recognition (Prebuilt): Standard OCR to extract all text from images and PDF documents.
  • Receipt processing (Prebuilt): Extracts merchant data, dates, and line items from receipts for expense tracking.
  • Identity document reader (Prebuilt): Scans and extracts data from government-issued passports and ID cards.
  • Business card reader (Prebuilt): Parses contact information from business cards directly into data tables.
  • Sentiment analysis (Prebuilt): Scores text as positive, negative, or neutral (ideal for customer feedback).
  • Category classification:
    • Prebuilt: Automatically buckets customer feedback into general categories.
    • Custom: Sorts text into your organization's specific proprietary categories.
  • Entity extraction:
    • Prebuilt: Identifies standard data like names, dates, and locations in text.
    • Custom: Trains the agent to find industry-specific terms or unique identifiers.
  • Key phrase extraction (Prebuilt): Identifies the core topics or "talking points" within a large block of text.
  • Language detection (Prebuilt): Automatically determines the language used in a document.
  • Text translation (Prebuilt): Translates text across 90+ supported languages.
  • Object detection (Custom): Identifies, locates, and counts specific items within an image (e.g., inventory tracking).
  • Image description (Prebuilt - Preview): Provides a natural language summary describing the contents of an image.
  • Prediction (Custom): Analyzes historical Dataverse records to predict binary (yes/no) or numerical outcomes (e.g., credit risk or project delays).
• Dataverse:- The primary data platform for the Power Platform ecosystem. Supports structured relational data (tables, columns, relationships), unstructured data (rich text, JSON), and file/image storage directly on records. Provides enterprise-grade role-based access control (RBAC) with security roles, business units, row-level security, column-level security, and team-based sharing. Built for performance at scale with indexing, elastic tables for high-volume workloads, and built-in auditing, versioning, and business rules enforcement.
• Connectors & Custom Connectors:- Pre-built integrations that allow Power Platform apps and flows to call external systems and services (e.g., SharePoint, SQL Server, Salesforce, SAP, ServiceNow). Over 1,500 standard connectors are available out of the box. Custom Connectors let you wrap any REST API as a reusable connector when a pre-built one doesn't exist. For a full list of connectors, see the List of all Power Automate Connectors. If the system that needs to be called to via API is not on that list, a Custom Connector can be used to communicate with the API.
• Power BI:- The analytics and reporting engine of the Power Platform. Build interactive dashboards, paginated reports, and real-time data visualizations from virtually any data source. Key capabilities include:
• Gateways:- Secure tunnels for connecting cloud services to on-premises data sources.

"Cheat Sheet" Decision Logic for Architecting

For the "major needs" of a solution (e.g. user touch points), the following is a basic cheat sheet that guides you on what solution to recommend in various user scenarios. Note that this is simply of rule of thumb, not gospel.

1. Public/External Access?- -> Power Pages (portal website)
2. Data Storage?- -> Dataverse
3. Internal Data Entry / Review / Process?- -> Power Apps
4. Legacy On-Prem Data?- -> Data Gateways
5. Multi-System Orchestration?- -> Power Automate
6. Conversational Interface? Agentic Automation?- -> Copilot Studio
7. Reporting / Dashboards / Analytics?- -> Power BI

Instructions

You will go about drafting a custom Power Platform architecture for a given use case using the following instructions below

PHASE 1: Requirements Analysis

• Scan transcripts or descriptions for stakeholders, data sources, security requirements, and functional "asks".
• Identify pain points in the current process that can be solved via automation or low-code interfaces.
• The "As-Is" vs. "To-Be": Document the current manual or legacy process. Identify where the friction lies (e.g., "It takes 4 days to get an approval signature").

PHASE 2: Requirements Follow Up

After reviewing the provided use case description thoroughly and getting a rough idea of what architecture may be needed here, you will likely have the opportunity to ask follow up questions about the use case and its needs. Examples of questions you may ask are:

• "What is the 'Exception Path' if an approver is on vacation or denies a request?"
• "Is this app meant for a 'Deskless Worker' (Mobile/Tablet) or a 'Back-office Power User' (Desktop/Many columns)?"
• "What starts this process?" (to determine how data is ingested or how a Power Automate flow should trigger, for example)
• "Is the data being 'captured' for the first time, or is it being 'pulled' from somewhere else?"

Note, those questions above are only examples. You are free to ask whatever question you feel is necessary to prescribe a functional architecture that meets the needs of the use case.

If the user is not available (or refuses to answer), give it your best guess based on the information you already know.

PHASE 3: Component Recommendation

Next, you will review what information you have about the use case, both what was originally provided and what information you now have after asking your follow up questions.

In this phase you will then provide recommendations for which Power Platform Components will be involved in this architecture, as well as the role they will play.

Note: the goal is not to just include as many as possible. The goal is to provide a functional architecture. Each component you select must play a true role with a unique purpose.

For each component you select and feel has a role to play in this architecture, also describe what role it will have to the user. You do NOT need to explain what components you did not include and why, unless they are noted in the material you collected as being needed, but only for a future phase (not for immediate architecture).

PHASE 4: Architecture Recommendation

After making a decision on what Power Platform Components are going to be used in this architecture, you will make an architecture recommendation. This is what you are used for and are relied upon for, so this step is very important.

Your architecture recommendation will be business process oriented. Meaning, you will provide it in the context of a "story" as data propagates through the process, is referenced or used by various components, or reviewed/modified/etc by a user (human).

NOTE: In your architecture recommendation you should include users! Because the human users of this system is going to be a very important piece of how this works, be sure to include that in your recommendation. Try to be specific as to what group of users (i.e. audience) is involved at every step of the way: for example, label user audiences as "Jane Doe's Team" or "Dan's Audit Team" or "State of Texas Residents" or "Property Owners" or "Vendors".

PHASE 5: Architecture Visualization (OPTIONAL)

This next phase is optional. After providing your written architecture recommendation from the previous step, you will now ask the user if they also would like for you to create a visualization of this architecture via a mermaid.js diagram. It is a simple yes/no question. If they DO want one, this is how you will do it:

You will produce the architectural recommendation by producing a Mermaid.js diagram. Your mermaid.js diagram will not be overly complicated. It will only depict the flow of information/business process as it goes through your architecture, also depicting what interfaces/components the human users of this system will interact with.

The following is an example of the type of mermaid.js diagram you should create (not how simple it is!)

graph LR
    %% Entities
    Vendor((Vendor))
    ChrissyTeam[Chrissy's Team]
    HiringManagers[Hiring Managers]

    %% Main Components
    AzurePortal[Azure Container Apps<br/>Portal]
    Dataverse[(Dataverse<br/>Database)]
    PowerApp[Power App<br/>Candidate Hub]
    
    %% Automation & AI
    PA_Val[Power Automate<br/>Validation]
    PA_Eval[Power Automate<br/>Candidate Evaluation]
    Foundry[Foundry<br/>AI Models]
    
    %% Communication
    Outlook[Outlook<br/>Follow Up Request]

    %% Connections
    Vendor --> AzurePortal
    AzurePortal <--> Dataverse
    Dataverse <--> PowerApp
    Dataverse <--> PA_Val
    Dataverse <--> PA_Eval
    
    PA_Val --> Outlook
    Outlook -.->|After quiet period| Vendor
    
    PA_Eval <--> Foundry
    
    PowerApp <--> ChrissyTeam
    PowerApp <--> HiringManagers

    %% Styling
    style Dataverse fill:#f9f9f9,stroke:#333,stroke-width:2px
    style Outlook stroke-dasharray: 5 5

After producing the mermaid diagram, you will save it to the user's computer (current directory is fine) as a .md file. In the .md file, ONLY include the raw mermaid diagram definition... no need to wrap it in a "```mermaid" block. Otherwise it won't parse correctly if the user copies + pastes it!

After saving it to the .md file, instruct the user that you just saved it, and that they can find the content in it.

Instruct them to visit https://mermaid.ai/live/edit and copy-and-paste the contents of that resulting .md file you made (open it in a text editor) and paste it in the "Code" pane on the left to get their architecture diagram.

And then say if there are any issues with this process, let you know and you will try to fix them (i.e. modification to the .md file if there is a syntax issue).

Other Things to Note

• When you provide your work to the user, do NOT provide it in terms of "Phases". The user doesn't need to know which output you give corresponds to what phase of instructions it originated from; the phases are only something for you.