Power Platform Documentation Generator

Sagar Pandey — Tue, 29 Sep 2026 05:47:11 +0000

Documenting a Power Platform solution shouldn't mean expanding every node of a 200-action flow. 😅

I built pp-pedia, a Power Platform documentation generator and AI assistant that runs 100% in your browser.

Drop in your solution ZIP and it will:

📦 Extract and parse the solution (flows, apps, tables, columns, choices, web resources)
📝 Generate readable documentation, with an interactive reader
🔎 Build vector embeddings in a Web Worker and store everything locally in PGlite
📤 Export the documentation when you need it

Then ask it questions: (optional, bring your own key)

💬 "What's the blast radius if I rename the cr_approval_status column?"
💬 "Which flows use premium connectors?"
💬 "If I make cr_tax_id required, which flows or apps might fail on record creation?"
💬 "Do any of our JS web resources use deprecated APIs like Xrm.Page?"

Why client-side?
Solution archives often contain business logic and schema details you can't upload to a random server. Here nothing leaves your machine. The only exception is if you choose to plug in an LLM provider, and then only the queries and retrieved context go to that provider.

Under the hood: a RAG pipeline with an agentic loop that calls client-side tools, so answers are grounded in your actual solution rather than guesses.

It's open source (Apache-2.0), so try it, break it, and tell me what's missing. 🙌

🔗 Try it: https://sagarpandey88.github.io/pp-pedia/
⭐ Code: https://github.com/sagarpandey88/pp-pedia

yet another git branching strategy

Sagar Pandey — Tue, 17 Sep 2024 11:36:31 +0000

Overview

git branch management is something i am sure we all struggle.

Application which are platform dependent might face this problem quite frequently as the platform licensing restrict them to have unlimited dev environment which is not the case for open source dependent application. Thus git flow or trunk based approach doesn’t suit well here. I want to publish this approach to have a discussion/debate around it and if possible get a better suited approach which others are using. Burn the comments section for the same.

You are free to make a pass if you don’t fall under this scenario.

When there are multiple teams working on same git repository and the release plan is highly agile. ie. when story/feature will be deployed is not certain , in that case a master/main branch based approach results in minimum conflicts. I have named this master/main affinity based branches as “mainly”.

The core of this approach is to have a feature branch from main branch and merge it wherever needed till the lifecycle of the feature.

1. Regular Development Cycles

1.1 Working on features using master/main based branches

Create a branch from master , name it feature/_FeatureName Ex: feature/58484_Login
Raise a PR to Environment Branch Ex: UAT Branch or a release branch
Run the pipelines from the Environment/Release branch.

1.2 Conflicts resolution

Create a intermediate branch from Environment branch

Ex: UAT_featurename_Merge from release/UAT_BRANCH
Merge your feature branch to Environment branch

i.e. merge feature/login —> UAT_featurename_Merge
Raise PR from intermediate branch to environment branch

i.e. UAT_featurename_Merge —> release/UAT_BRANCH
Successive changes can be directly PRed from feature to enviroment branch.

i.e. feature/login —> release/UAT_BRANCH

2. Moving to upstream environments (PROD)

Assume we have feature branches feature/login , feature/myProfile and feature/myContacts

Only login and myProfile are planned to be release to upstream environment.

Create a release branch Ex: release/master_v1
Raise PR and merge feature/login and feature/myProfile
Raise a PR from release/master_v1 to main
Run the pipelines either from main or if you want to stage your changes then stage it from release/master_v1