Skip to content

Home

Jump to bottom
RemyDuijkeren edited this page Jul 3, 2026 · 35 revisions

Flowline is a Dataverse ALM CLI — a professional Git-based workflow for plugin developers and solution architects, without the overhead of Power Platform Pipelines or managed solutions.

PAC CLI gives you the primitives. Flowline gives you the workflow: clone → push → sync → deploy, from the inner dev loop to production, in one tool.

Where PAC CLI already handles it, Flowline wraps — it doesn't re-implement. Where PAC has no answer, Flowline fills the gap.

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.
  • Orphan cleanup built in. push deletes plugin steps, step images, and web resources that no longer exist in source — DEV stays in sync with your code automatically. deploy cleans up solution components removed since the last import, and reports manual components you need to handle yourself. No stale registrations, no ghost records. Use --no-delete to opt out.
  • 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.

A few convictions that shape every design decision:

  • Code flows up, configuration flows down — DEV is the verification gate. Code assets are source-driven: push deploys them to DEV, orphans deleted. Dataverse configuration is environment-driven: sync snapshots DEV into source control. deploy promotes the verified DEV state — what was tested — not current local source. Git is the audit trail of verified states, not the authoring surface for Dataverse configuration.
  • Convention over configuration. Plugin steps inferred from class names. Dependencies inferred from base-name and in-source annotations. No config files duplicating what the code already says.
  • Safety before action, confidence before commitment. Every destructive operation has --dry-run. Every guard has an explicit escape hatch. Protect by default, trust explicitly.
  • Unmanaged is a legitimate professional choice. Orphan cleanup, Git-tracked solutions, and DTAP gates close the gaps that made managed solutions look necessary. The package type was never the problem — the tooling was.
  • AI-native, not AI-bolted-on. Structured exit codes, verbatim corrective actions, always-current DATAVERSE_CONTEXT.md, self-healing AGENTS.md — one coherent system, not a collection of AI features.

Full reasoning and evidence: 10-Philosophy

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 getting less maintained.

When PAC CLI appeared as Microsoft's official Power Platform CLI, the smart move was obvious: lean into it. Auth, solution import/export, and environment management were now owned by an official Microsoft tool — delegate that, don't re-implement it. Build only what PAC couldn't: the tight developer workflow from inner dev loop to production.

Daxif introduced a sync philosophy that works well for me: push makes Dataverse match source, no orphans, liked the generated C# types. The team at Delegate A/S deserves real credit, love their tools. 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