Packages

A package keeps the parts of a solution together. It can include workflows, triggers, data stores, dashboards, and agent tools, along with the setup information another organization needs.

Open Packages and choose a view:

• Marketplace — packages available to install.
• Installed — packages already added to this organization.
• Published — packages your organization owns and publishes.

Find a package

Search the Marketplace by name or package handle. Filters help you find packages verified by QuickFlo or packages that include agent tools.

Open a package before installing it. The detail page shows:

• the publisher, version, and verification status;
• a plain-language description and README;
• the workflows, triggers, data stores, dashboards, or tools inside;
• the connections and environment values it needs from your organization.

A package can be large and still be easy to adopt when its required mappings are clear. Review Needs from your org before you install.

Install a package

Select Configure and install. QuickFlo walks you through the resources that will be added and the organization-specific values that cannot travel with the package.

You may need to provide:

• Connections — choose one of your own authorized accounts.
• Environment values — enter or map configuration for this organization.
• Data store choices — create the packaged table or map to an existing one when supported.
• Extension points — choose a compatible sub-workflow for an intentionally replaceable part of the solution.

Credentials never come from the publisher. You always authorize your own connections.

Review the final resource list before confirming the install. If setup remains, the installed package shows what needs attention.

Tip

Install into a test organization first when a package creates schedules, public triggers, or workflows that can change external data.

Work with an installed package

The Installed view shows what your organization has added. Open an installation to see its version, resources, mappings, and available updates.

Package-owned resources stay connected to the installation. You can inspect them like any other QuickFlo resource, but an update may replace the publisher-owned definition.

If you need a lasting local variation, duplicate the workflow or dashboard and treat the copy as organization-owned. Keep packaged resources close to the published shape so future updates remain understandable.

Data in an installed data store belongs to the installing organization. Updating a package should not be used as a way to replace operational records.

Publish a package

Use Published when you want to distribute a solution you maintain.

A reliable publishing path is:

1. Choose the workflows that form the public entry points.
2. Review the triggers, sub-workflows, data stores, dashboards, and tools QuickFlo discovers with them.
3. Remove customer-specific names, destinations, and sample data.
4. Describe each connection and environment value the installer must supply.
5. Add setup and test instructions to the README.
6. Publish a version and install it in a clean organization.

Package dependencies are discovered from the selected resources. Review that graph rather than maintaining a second dependency list by hand.

Data stores and seed data

Most packaged tables should install empty. Include seed rows only when they are part of the solution itself, such as a status map or default configuration.

Do not include leads, orders, call records, or other operational data. Those records belong to the organization using the package.

Connections and environments

Packages record that a connection or environment value is required, not its secret value. The installer maps each requirement to their own organization.

Use logical, documented names. CRM_CONNECTION and ALERT_CHANNEL explain intent better than a customer name copied from the publishing organization.

Extension points

An extension point is a supported place for the installer to supply their own sub-workflow. Use one when a solution has a stable outer shape and one deliberately customer-specific decision, such as scoring, routing, or enrichment.

Keep the contract small: document the input the extension receives and the result the package expects back.

Release an update

Publish a new version when the packaged solution changes. Before release:

• test a fresh install;
• test an update from the previous version;
• confirm existing mappings still resolve;
• call out any resource that will be replaced or removed;
• verify schedules and public triggers remain in the intended state.

Use the CLI & Agent Skill when package publication is part of a repeatable release process.

Packages or copied workflows?

Copy and paste is best for a small example you intend to own immediately. A package is better when the solution has several resources, needs versioned updates, or must guide the installer through connections and environment mappings.

For small building blocks, browse the Workflow Library. For clipboard details, see Copy and Paste Workflows.