add-datasource

> **Plugin check**: Run `node "${PLUGIN_ROOT}/scripts/check-version.js"` - if it outputs a message, show it to the user before proceeding. **📋 Shared instructions: [shared-instructions.md](${PLUGIN_ROOT}/shared/shared-instructions.md)** — read first. # Add Data Source **Entry routing:** use the shared [App feature entry points](../../shared/shared-instructions.md#app-feature-entry-points) preflight before the workflow below. **Invocation scope:** follow [Data-source invocation scope](../../shared/shared-instructions.md#data-source-invocation-scope) before any project read or the workflow below. Resolve the absolute app root before reading memory-bank. Routing selects a data workflow, not implementation approval or a full-app integration workflow. Router skill that understands the user's goal and connects them to the right data source — without requiring them to know Power Platform terminology. ## Workflow ### Check Memory Bank Check for `memory-bank.md` per [shared-instructions.md](${PLUGIN_ROOT}/shared/shared-instructions.md). ### Understand the Goal 1. **If `$ARGUMENTS` is provided or the caller already specified what's needed**, use it directly and skip the question below. 2. Otherwise, ask the user **what they want their app to do** — not which connector to use. Focus on the end goal. Example questions: - "What kind of data does your app need to work with?" - "What should your app be able to do? (e.g., search company info, manage tasks, send messages)" 3. Based on their answer, **recommend the best approach** and explain *why* it's the right fit. The user shouldn't need to know the difference between Dataverse, SharePoint, or other connectors — that's our job. ### Route to the Right Skill **Telemetry checkpoint: `route_data_source_request`** | User's goal | Best approach | Invoke | |---|---|---| | Refresh generated services for a retained data source | Resolve the existing registration; preserve its platform and binding | Matching `/add-dataverse`, `/add-sharepoint`, or `/add-connector` with skill-only `--refresh --data-source-name "<registered-name>"` | | Stop using a registered table or connector in this app | Preserve the removal intent and resolve its existing registration type; do not infer a new data platform | Matching `/add-dataverse`, `/add-sharepoint`, or `/add-connector` with skill-only `--remove` | | Store and manage structured business data (custom tables, forms, CRUD) | Dataverse is the platform's native database | `/add-dataverse` | | Invoke an existing Dataverse action/function/API | Discover with `pa app find-dataverse-api`; this plugin only adds Dataverse table CRUD | `/add-connector` | | Read lists, manage documents, integrate with SharePoint sites | SharePoint Online — dedicated skill with list creation support | `/add-sharepoint` | | Add, invoke, refresh, or remove a Power Automate cloud-flow binding | Cloud-flow integration is not supported by mobile skills | None; report the limitation and return without CLI calls | | Anything else — Teams messages, Excel data, OneDrive files, Office 365 email/calendar, Azure DevOps, Copilot Studio, custom connectors | Generic connector (we'll figure out the right one) | `/add-connector` | **Note:** Dedicated skills for Teams, Excel, OneDrive, Office 365, and Azure DevOps are planned for v1. Until then, `/add-connector` handles all of them — it covers every connector the platform supports and generates the same `src/generated/` service layer. **Important routing rules:** - Forward the absolute `working_dir`, current request, owner/phase/scope, supplied answers, and `--plan-only` or planning-phase status unchanged on every handoff. Standalone calls use the selected leaf's own approval and verification gates; a saved plan or router choice is not consent to mutate. - For refreshes, forward the exact registered identity, `--refresh`, `--data-source-name`, proposal-only status, and current approved scope to the matching leaf. Never convert a refresh into an add or request a new connection. Conflicting add/refresh/remove scopes return to the owner for separate calls. - For removals, forward the approved identities and scope unchanged to the matching leaf's removal branch; never turn "remove this source" into an add command. Use [data-source-removal.md](../../shared/references/data-source-removal.md). - When the user wants to **perform actions** (send an email, post a Teams message, create a file), route to `/add-connector` with the connector name as the argument (e.g., `/add-connector office365`, `/add-connector teams`). - For a **cloud-flow binding** request, report `BLOCKED: cloud-flow integration is not supported` and return without discovery or mutation. Do not route it through a connector or Dataverse workflow. - When the user wants to **invoke a Dataverse action/function/API** rather than table CRUD, route to `/add-connector` and tell it to use `$PA app find-dataverse-api --search '<operation-name>' --json`; then stop and explain that this plugin only adds Dataverse table CRUD. - When the user wants to **store or query structured business data** with custom schema, route to `/add-dataverse`. 4. If the approved scope includes multiple capabilities, invoke each skill in sequence and return the combined results to the user or current owner. Do not independently expand a connector request into schema or screen changes. ### When the User Isn't Sure If the user describes a vague goal (e.g., "I need data for my app"), guide them: 1. Ask what their app does and who uses it 2. Ask what data they need to display or interact with 3. Recommend the simplest approach that meets their needs 4. Explain the recommendation in plain language (avoid jargon like "connector", "Dataverse", "tabular data source" unless the user uses those terms first)