Skip to content

Home

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

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

Attribute-driven plugin registration that covers Custom APIs, a full Git-based ALM loop from dev to prod, and automatic web resource dependency registration — in one tool. Where PAC CLI already handles it, Flowline wraps — it doesn't re-implement. Unlike Power Platform Pipelines, Flowline requires neither Managed Environments nor managed solutions.

Familiar with spkl? Flowline is its actively maintained successor (last meaningful commit 2021).

What sets Flowline apart

  • Attribute-driven plugin registration. Decorate IPlugin classes with [Step], [Filter], [PreImage], [PostImage], and [CustomApi] — Flowline reads the compiled assembly and handles every Dataverse registration automatically. No Plugin Registration Tool needed. spkl.json unnecessary. Plugins, workflow activities, and Custom APIs all in one assembly, one pass.
  • Automatic web resource dependency registration. push links RESX files to their parent JS by base-name and wires JS-to-JS dependencies from // flowline:depends annotations — on every push, automatically. No Maker Portal visits, no manual dependency trees to maintain.
  • Source is the truth — always. Plugin steps, step images, and web resources that no longer exist in source are deleted from Dataverse on every push. No stale registrations, no ghost records, no manual cleanup. Use --no-delete to audit before acting.
  • AI-native schema context. After every sync, Flowline writes DATAVERSE_CONTEXT.md — a curated snapshot of your entities, attributes, option sets, forms, views, workflows, and plugin steps. Claude Code, Copilot, and Codex load it automatically via AGENTS.md. Your AI assistant knows your schema without live queries or copy-pasted field names.
  • Human-readable sync summary. sync doesn't just dump XML diffs — it translates them. Entities and components added, changed, or removed; attribute-level detail; column changes in views; option changes in option sets. You know exactly what changed before you commit.
  • Scaffolded WebResources project. clone creates a TypeScript + Rollup project ready to go — dist/ is automatically wired to push. No boilerplate, no manual configuration. Swap in any bundler you prefer.
  • Dry-run before you touch anything. Every destructive operation supports --dry-run — see exactly what Flowline would register, update, or delete before a single Dataverse record is touched. Run it in CI as a safety gate, or any time you want confidence before committing. No other Dataverse ALM tool offers this.
  • Zero-friction auth. Flowline reuses the PAC CLI auth profiles you already have — no extra login steps, no client secrets in scripts, no Windows Credential Manager setup. Switch environments by switching PAC profiles. Works in CI with service principals out of the box.
  • One-command environment provisioning. provision copies PROD to a fresh DEV or TEST environment in one command — no manual admin center clicks, no configuration drift.

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