Packages

A package is a versioned bundle of QuickFlo resources you publish once and install many times. Use packages to ship a working integration across orgs without copy-pasting workflow JSON, manually re-creating data stores, or rebuilding dashboards from scratch.

What can you bundle

A single package can include any mix of:

Workflows — every workflow you select, plus any sub-workflows they call. Sub-workflows are found by walking the call graph, so you pick the entry points and their dependencies come along.
Triggers — the webhook, cron, event, and chat triggers attached to those workflows.
Data stores — the tables the workflows read from or write to.
Dashboards — their widgets, filters, layout, and the data sources they query.

Connections are handled differently. A package records what kind of connection each workflow needs (a Salesforce connection, an HTTP credential) but never the connection itself. The consumer binds their own at install. Credentials never travel between orgs.

When a package contains a dashboard, the data store tables it queries are bundled with it. The consumer gets the dashboard and the empty tables it depends on, ready for their own data to land in.

Seed data

By default a packaged data store ships the table but no rows: the consumer gets an empty table ready for their own data. But not every table is runtime data. Some are configuration: a lookup table of statuses, a set of default settings, a mapping the workflows read on every run. For those you want the rows to travel with the package.

On the Review step you can mark a table to include data. Up to 1,000 rows are snapshotted into the artifact. The rule of thumb is on the screen: include data for config and lookup tables, leave it off for runtime data like leads or orders.

On a fresh install those rows land in the new table automatically, so the package works out of the box. On reinstall the consumer’s rows are kept by default: a table they’ve been writing to is theirs, and an upgrade won’t silently overwrite it. If they do want the publisher’s latest seed rows, they opt in per table (“reset to package defaults”), which upserts the bundled rows by key.

Publishing a package

From the Packages page, click New package and walk through the wizard:

Details — name, version (semver), visibility (private / unlisted / public).
Contents — pick the workflows, triggers, data stores, and dashboards. Dependencies attach themselves: a workflow pulls in its sub-workflows and the data store tables it touches; a dashboard pulls in its data sources.
Review — inspect the dependency graph QuickFlo assembled, and catch problems before they ship.
Defaults — optionally ship default values for the package’s shared env keys. The consumer can override them on install.
Distribution — publish the version. You can download the .qfpkg artifact here too. On publish, QuickFlo mints the install URL for unlisted and public packages and hands it back on the confirmation screen.

How connections and env vars become mappable

QuickFlo works out a package’s connection and env requirements at publish time by scanning the bundled workflows for {{ $connections.* }} and {{ $env.* }} references. At install time each one becomes something the installer asks you to map: a connection to attach, an env value to fill. You don’t maintain that list yourself.

One thing is rejected at publish: hard-coding another org’s private env values. A {{ $env.<environment>.KEY }} reference belongs to your org, not the consumer’s, so the wizard offers to rewrite it to a flat key or move it to shared.

Installing a package

Customers install via a shared link or the Packages library inside QuickFlo. Install runs in three phases:

Preview — the full list of resources the install will create: workflows, triggers, dashboards, data sources, data store tables. Nothing is written yet.
Mapping — you bind the package’s peer dependencies to your own org (see below).
Commit — every resource lands in a single transaction. Either the whole install succeeds or nothing is written, so a failure never leaves half a package behind. Anything that still needs your attention surfaces as a setup-checklist item.

What you map

Connections — point each connection requirement at one of your own connections. Connections are never created during install: they hold secrets and need provider authentication, so an unmapped connection becomes a checklist item (“authenticate Salesforce”) you complete afterward.
Environment — pick which environment each workflow reads its {{ $env.X }} values from. Shared keys auto-match against your org’s shared env; where the publisher shipped a default it’s pre-filled; anything still empty becomes a checklist item. Schedule triggers can take an environment of their own.
Data store tables — reuse an existing table by name, or let the install create a new one. Where a table ships seed data, you choose keep-current or reset-to-package-defaults.
Extension points — bind the package’s customization slots to your own sub-workflows (see below).

Extension points

An extension point is a slot the publisher leaves open on purpose. The package ships a main workflow with one piece of logic factored out into a sub-workflow you’re meant to replace: a lead-enrichment step, a routing decision, a scoring rule. Rather than bundle one fixed implementation, the publisher declares the slot, ships a working starter, and lets each consumer plug in their own.

A declared extension point carries a name and label, the starter sub-workflow, whether it’s required, and an input/output contract: the data the main workflow sends in, and what it expects back.

On first install the starter is copied into your org and wired up automatically, so the package runs as shipped. Customizing is an optional checklist nudge, not a blocker.
To customize, point the slot at one of your own sub-workflows. QuickFlo checks it against the contract: your workflow has to accept what the package sends and return what the rest of the package depends on. Compatible candidates are offered; ones that would break the contract are flagged.
On reinstall your binding is remembered. You can keep your sub-workflow, switch to another, or reset to the publisher’s latest starter.

A package can be opinionated about the overall workflow and still leave the customer-specific part open.

Reinstall semantics

Installing a newer version of a package you already have is a reinstall, not a separate install. QuickFlo diffs the new version against your current install and applies the delta:

Workflows / triggers / dashboards added in the new version — created fresh.
Workflows / triggers / dashboards updated — replaced in place. The resource’s QuickFlo ID stays stable across reinstalls, so any bookmarks, embed links, or URLs your team has keep working.
Resources removed in the new version — deleted from your org.
Customer-owned data — never touched. Data store rows survive uninstall and reinstall; the package manages the tables themselves, not the rows your org writes into them.

Dashboards in packages

A pack-managed dashboard renders with the publisher’s layout, widgets, and filters. You can edit it in your org; nothing locks it. But a reinstall replaces it wholesale, so your edits are gone at the next upgrade. The reinstall flow warns you before overwriting a managed dashboard you’ve changed.

If you want changes that survive upgrades, duplicate the dashboard first (dashboard menu → Duplicate). The copy is customer-owned, and reinstalls leave it alone. Edit the copy freely.

It works the way editing a dependency does: you can change the installed copy, but the next install overwrites it. If the change matters, fork it.

Versioning

Packages use semver — 1.2.3 style. Each publish creates a new immutable PackageVersion with a snapshot of every resource. Customers see a version history and can roll forward or pin to a specific version.

You can publish a new version from the published-package detail page → “Publish new version.” The wizard pre-populates with the previous version’s selections, so you adjust from there rather than re-selecting from scratch.

Distribution

Three visibility modes:

Private — only visible inside your own org. Useful for internal-only templates.
Unlisted — anyone with the install URL can install. The URL contains an opaque token; rotating it via the package detail page invalidates old links.
Public — listed in the QuickFlo public package library. Searchable.

Verified packages get a check-mark badge after a QuickFlo-team review. Reach out if you want yours reviewed.

CLI

You can also publish + install packages from the @quickflo/cli. Useful for CI/CD pipelines that auto-publish on tag or commit.