From powerplatform-bestpractices
Power Platform ALM best practices. Use when the user asks about solution design (managed vs. unmanaged, how to split solutions, stability layers), solution naming or versioning, publisher prefix configuration, environment strategy (dev/test/prod), solution dependencies, or deployment pipelines (Azure DevOps, GitHub Actions, Pipelines for Power Platform). Also use when the user asks "what solution should I put X in" or "how do I deploy to test/prod".
How this skill is triggered — by the user, by Claude, or both
Slash command
/powerplatform-bestpractices:ppbp-almThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Work in progress** — Deployment pipeline guidance (PAC CLI sequences, Azure DevOps / GitHub Actions YAML) will be added in a future iteration. Solution design conventions below are stable.
Work in progress — Deployment pipeline guidance (PAC CLI sequences, Azure DevOps / GitHub Actions YAML) will be added in a future iteration. Solution design conventions below are stable.
dataverse:dv-solution — exports, imports, and manages Dataverse solutions. Load this official skill before applying the guidance below. If it is not installed, strongly recommend the user install it before proceeding.
ALM assets do not have a dedicated top-level folder — they live in platform-standard locations (see ppbp-overview for the full canonical tree):
<repo-root>/
├── .github/
│ └── workflows/ # GitHub Actions deployment pipelines
└── pipelines/ # Azure DevOps pipeline YAML (alternative to .github/workflows/)
Power Platform solutions are managed in the platform itself, not stored in the repository as unpacked XML unless the project explicitly exports them. If solution XML is committed, store it under solutions/<solution-unique-name>/.
Functional name (Display Name): readable, business-facing. Title case, no technical jargon.
Contoso Core, Contoso Integrations, Contoso Portalsolution1, MyCompany_Core_v2_FINAL, Pkg_ProdTechnical name (Unique Name): <PublisherPrefix>_<ProjectCode>_<Layer> — all segments separated by underscores, no spaces, PascalCase layer name.
prfx_code_Core, prfx_code_Integrationsprfx_core (missing project code in shared env), prfxCodeCore (no separators)In a single-project environment the project code segment may be omitted: prfx_Core.
Use Major.Minor.Patch.Build (e.g. 1.2.0.0).
| Increment | When |
|---|---|
| Major | Breaking change — table removed, column type changed, public API changed |
| Minor | New feature — new table, new flow, new app added |
| Patch | Bug fix or non-breaking config change |
| Build | CI/CD pipeline counter (auto-incremented, never set manually) |
Never ship managed solutions with 0.x versions to production. Reach 1.0.0.0 before the first prod deployment.
Split solutions along stability and release cadence, not by asset type.
| Layer | What belongs here | What does NOT belong |
|---|---|---|
| Base / Shared | Publisher, global Choices, shared reference tables, security roles | App-specific tables, flows that depend on app logic |
| Core domain | Domain tables, relationships, business rules (plugins, Custom APIs) | UI apps, integration flows |
| App layer | Canvas/model-driven apps, site maps, forms, views | Tables that other solutions depend on |
| Integration layer | Flows, connectors, external-facing Custom APIs | UI assets, core domain tables |
Rules:
Document the dependency chain in the project README.md (see ppbp-overview). The import order at deploy time must exactly match the declared dependency graph — enforce this in your pipeline.
| Anti-pattern | Correct approach |
|---|---|
| One solution for the entire project | Split by stability layer — Base → Core → App/Integration; reduces blast radius of changes |
| Importing solutions out of dependency order | Declare the full dependency graph in README and enforce order in the pipeline |
Versioning with a date suffix (_20250601) | Use semantic Major.Minor.Patch.Build; dates as versions break upgrade detection |
Setting version to 1.0.0.0 before prod is ready | Keep 0.x during active development; go to 1.0.0.0 only on first prod release |
| Mixing UI assets and domain tables in the same solution | Domain tables change less often than UI — separating them lets you ship UI updates without touching schema |
Work in progress — PAC CLI export/import sequences and pipeline YAML (Azure DevOps, GitHub Actions) will be documented here. In the meantime, refer to the official
dataverse:dv-solutionskill for current export/import commands.
This skill covers solution design, naming, versioning, and deployment pipeline patterns. It does not cover:
ppbp-overviewppbp-dv-metadatappbp-code-appsppbp-dv-pluginsppbp-generative-pagesnpx claudepluginhub tchinnin/powerplatform-bestpractices-skillsSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.