Console & config

Commands

php craft fjord/flows                     # the flows and their steps
php craft fjord/flows/routes              # the site routes Fjord contributes
php craft fjord/flows/check               # preflight
php craft fjord/flows/export              # the whole configuration as JSON
php craft fjord/flows/export springLaunch --file=spring.json
php craft fjord/flows/import --file=spring.json
php craft fjord/flows/install-templates   # copy the reference templates into your site
php craft fjord/stats/report [handle] --days=30
php craft fjord/stats/prune

fjord/flows/routes is the fastest way to find out why a step 404s: it prints exactly what Fjord has contributed to the site's URL rules, per site.

Moving funnels between environments

There are two ways, and Settings → Where funnels are stored chooses between them.

In the database (the default). Funnels can be edited on any environment, the live site included, which is usually what whoever runs the marketing wants. export and import are how a funnel travels. Purchasables are written out by SKU as well as by ID, and read back by SKU first, so a product does not silently become a different product.

In project config. Flows, steps, A/B variants and offers are built where admin changes are allowed and deployed with the rest of the site, like sections and fields. Elsewhere Fjord's flow and offer screens are read-only, and saving, deleting, reordering and importing are refused — a change made there would be undone by the next deploy. Purchasables travel by SKU here too; flows name their site, steps their flow, and variants their step by UID, so no environment-specific ID is involved. Routing rules and offer conditions are stored as the condition builder writes them, so a rule that names a specific product or user carries that element's ID, as Craft's own conditions do.

Sessions, analytics, grants and webhooks stay in the database either way: they are what happens on a site, not how it is built. Switching in either direction keeps every funnel, and the choice is project config itself, so it deploys too. Only an admin can switch, where admin changes are allowed.

Importing a flow whose handle already exists replaces it wholesale rather than merging — a half-merged funnel is a funnel nobody can reason about. Offers are matched by handle and updated in place.

Settings

Setting	Default	Does
Template Root	shop/fjord	Where a bare step template name is looked up
Session Cookie Name	fjord_session	The cookie carrying a visitor's place in a funnel
Session Lifetime	72 hours	Inactivity before a funnel session is forgotten
Offer Window	60 minutes	How long after an order a one-click offer may still be charged
Require a Paid Order	on	Only offer an upsell once the parent order is paid
Replay Declined Offers	off	Show an offer again to someone who already refused it
Track Events	on	Record views and conversions
Event Retention	365 days	0 keeps them forever
Webhook Timeout	10s	How long to wait on an outbound webhook
Where funnels are stored	database	Database, or project config — see above. Admin-only
allowPrivateWebhookHosts	off	Config file only. Lets webhooks post to private and loopback addresses

Permissions

• Manage flows and steps
• Manage offers
• View funnel reports
• Manage webhooks

The control-panel section only appears for a user who has at least one of them.

What Fjord stores

Nine tables: flows, steps, variants, offers, the step–offer join, sessions, events, grants and webhooks. Deleting a flow cascades to its steps, variants, sessions and events. With funnels stored in project config, the first five tables are kept in step with it — Fjord still reads from them — and uninstalling removes Fjord's project config too.

Grants — the record of what each offer resolved to on each order — are deliberately not deleted with the order they belong to, and events are not foreign-keyed to orders at all. Commerce's own garbage collection can remove an order long after the funnel it came through, and losing the analytics row with it would silently rewrite history.