Skip to content

Home

Jump to bottom
RemyDuijkeren edited this page Jun 12, 2026 · 35 revisions

Flowline is a Dataverse ALM CLI — structured workflow, Git-tracked solutions, and a fast push to DEV without the enterprise overhead.

Flowline is the opinionated successor to spkl: attribute-driven plugin registration that now supports Custom APIs, web resource push without spkl.json, a full Git-based ALM workflow, and modern PAC auth.

What sets Flowline apart

  • Scaffolded WebResources project. clone creates a web resources project with Rollup + TypeScript already set up — dist/ is automatically wired to push. Swap in any bundler you prefer.
  • Fast push for code assets. push syncs plugin assemblies and web resources directly to DEV without a full solution import. Use from a Flowline project, or point at a standalone plugin file and web resource folder.
  • Keeps Dataverse in sync with source. Plugin steps, images, and web resources missing from source are deleted on push — no manual cleanup. Use --no-delete to skip.
  • Dry-run everything. --dry-run previews every change before it touches Dataverse.
  • Human-readable sync summary. After sync, Flowline translates the git diff into a developer-friendly summary — entities and components added, changed, or removed.
  • Attribute-driven plugin registration. Decorate IPlugin classes with [Step], [Filter], [PreImage], [PostImage], and [CustomApi]; Flowline reads the compiled assembly and handles Dataverse registrations.
  • Plugins, workflow activities, and Custom APIs in one assembly. Flowline reads all supported types from a single assembly in one pass.
  • One-command environment provisioning. provision copies PROD to a fresh DEV or TEST environment — no manual admin center clicks.
  • Progressive adoption. push and generate work standalone — no .flowline config required. Start with flowline push on an existing project; adopt the full workflow when ready.
  • Modern auth. Flowline reuses the PAC CLI token cache. No passwords, no client secrets in scripts, no Windows Credential Manager.

Pages

Design

PAC CLI is Microsoft's official Power Platform CLI — the authoritative tool for auth, solution import/export, environment management, and component operations. Flowline treats it as a first-class dependency and uses it wherever it already does the job.

Where PAC CLI overlaps, Flowline wraps — it does not re-implement. The goal is a better developer experience on top of PAC, not a parallel implementation that diverges from the Microsoft toolchain. When PAC CLI improves, Flowline benefits automatically.

Where PAC CLI has no answer — attribute-driven plugin registration, Git-based push loop, sync summaries, WebResources scaffolding — Flowline fills the gap with its own implementation.

PAC CLI gives you the primitives. Flowline gives you the workflow.

Why Flowline exists

Flowline started from a practical problem: Daxif handled the dev loop, NUKE Build handled the build and deploy pipeline — but both were aging and effectively unmaintained. When PAC CLI appeared as Microsoft's own Power Platform CLI, the goal became clear: one tool that covers both dev and build flow the way dotnet CLI does for .NET, built on top of PAC CLI rather than around it.

Daxif introduced a sync philosophy that works well for me: push makes Dataverse match source, no orphans, liked the generated C# types. But it is written in F#, which made it difficult to use and made community contributions nearly impossible; all maintenance had to go through the Delegate A/S team, which slowed down over time.

spkl is a solid C# alternative that many teams reach for, but didn't fit my flow. It requires a spkl.json file that duplicates information already in the project and didn't cleanup orphans by default. The biggest problem is that it has not been meaningfully maintained since 2021.

PAC CLI filled the auth and solution import gap, but the focus is on admin.

PACX tries to fill the missing gaps of PAC, but its focus is on scripting and broad component management — not the tight push inner loop of daily plugin and web resource development that I prefer.

Flowline takes what worked in each tool — Daxif's sync philosophy, spkl's attribute-driven plugin registration, PAC CLI's auth model — combines them in C# so anyone can contribute, and adds the pieces that were missing for this specific workflow: a coherent Git-based push loop from dev to prod in one tool, managed or unmanaged.

The Dataverse community will tell you unmanaged in production is amateurism. Flowline exists partly to disagree — loudly. The problem was never the package type; it was the tooling that made a professional workflow feel impossible without going managed. Git-tracked solutions, proper ALM, clean diffs, removing orphans, full auditability — all unmanaged, nothing to apologize for. (Managed deployment is supported too, if you want to go to the dark side.)

Why the name

In industry, a pipeline is rigid infrastructure: fixed diameter, fixed route, fixed rules. Microsoft's Dataverse Pipelines follow the same pattern — structured, opinionated, and built around managed solutions. That rigidity is useful when you need it, but it excludes teams that work differently.

A flowline is what engineers reach for when a pipeline doesn't fit. In oil and gas, flowlines are the flexible, small-bore connections used at the wellhead or at the end of a pipeline — where the terrain is uneven, the setup is temporary, or the fixed route simply isn't there yet. They carry the same thing as a pipeline, just on your terms.

Flowline CLI works the same way. Managed or unmanaged, strict ALM or fast inner loop, greenfield project or existing legacy repo — it adapts to how you work, not the other way around.

Clone this wiki locally