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 (auto-discovered)
• Triggers — webhook, cron, event, and chat triggers attached to the bundled workflows
• Data stores — the underlying tables the workflows read from or write to
• Dashboards — including their widgets, filters, layout, and the dashboard data sources they pull from

When you publish a package containing a dashboard, the underlying data store tables it queries are auto-bundled too. Customers who install the package get the dashboard and the empty tables it depends on, ready for their own data to land in.

Publishing a package

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

1. Details — name, version (semver), visibility (private / unlisted / public)
2. Contents — pick the workflows, triggers, data stores, and dashboards to include. Dependencies auto-attach (selected workflows pull in their sub-workflows and referenced data store tables; selected dashboards pull in their data sources)
3. Review — inspect the dependency graph QuickFlo built; check for issues before publishing
4. Defaults — opt into shipping default values for the package’s shared env keys (the customer can override on install)
5. Distribution — choose to also download the .qfpkg artifact alongside publishing
6. Publish — the package version is created; an install URL is generated for unlisted / public packages

Installing a package

Customers install via a shared link or the Packages library inside QuickFlo:

1. Preview — sees the full list of resources the install will create (workflows, triggers, dashboards, data sources, data store tables)
2. Mapping — binds peer dependencies: which connections to attach, which env values to use, which existing data store tables to reuse
3. Commit — every resource lands atomically; setup-checklist items surface any post-install tasks (authenticate a connection, fill in a missing env var, register a fresh webhook URL)

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; only schema definitions get replaced.

Dashboards in packages

Pack-managed dashboards are read-only in the consuming org. They render with the publisher’s intended layout, widgets, and filters — but you can’t edit them directly. To customize a pack-managed dashboard:

1. Clone it via the dashboard menu → “Duplicate.” The clone becomes customer-owned.
2. Edit the clone freely. Future reinstalls of the package leave your clone untouched.

This matches how npm packages or Rails plugins work — you can override at the consuming-app level, but you don’t edit the upstream artifact.

Cross-organization data sources can't be packaged

If a dashboard you’re trying to publish references a data source that reads from another organization (a partner-org share or cross-org aggregate), the publish will fail with a clear error message naming the source.

Workaround: either drop that dashboard from the package, or rebuild the data source against an org-local table before publishing.

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.