From 85e831ad0266e22c4f24ed58a0ca311200476738 Mon Sep 17 00:00:00 2001 From: dgatti0213 Date: Tue, 1 Sep 2026 11:57:07 -0700 Subject: [PATCH] handbook/sales: gate the PoV environment on outbound network access, not just install MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit For self-hosted installs, "FlowFuse installed" is not the same as a ready environment. If the environment can't reach the hosts FlowFuse needs to install and update nodes/packages, the PoV stalls the first time someone adds a node — a recent PoV lost a week to exactly this. Strengthen gate #5 in both the Solution "What the SE produces" list and the Pre-PoV checklist: the outbound access must be filed *and proven* during Solution, and links to the Networking requirements docs page for the host list to hand the customer's network team. Depends on FlowFuse/flowfuse#8354, which adds /docs/install/networking-requirements — keep this PR in draft until that merges (the link 404s until then). Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01KT4u2XgENWkw2Rm6oEXFXx --- nuxt/content/handbook/sales/meetings/pov.md | 2 +- nuxt/content/handbook/sales/meetings/solution.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/nuxt/content/handbook/sales/meetings/pov.md b/nuxt/content/handbook/sales/meetings/pov.md index a6ff44c53a..117d617d28 100644 --- a/nuxt/content/handbook/sales/meetings/pov.md +++ b/nuxt/content/handbook/sales/meetings/pov.md @@ -59,7 +59,7 @@ are met is the most common way one stalls. 2. **The apps are defined.** The app or apps that will solve the use case are identified and follow FlowFuse's app delivery methods, so the PoV showcases FlowFuse as an app-building platform — not a test of Node-RED. 3. **Success criteria are well defined.** Each criterion has a concrete, agreed pass signal, so "success" is not open to interpretation when the PoV ends. 4. **The plan is agreed with the customer.** Tasks, owners and dates are agreed jointly, not just internally. -5. **FlowFuse is available to test.** The customer has either installed FlowFuse (self-hosted) or signed up for a Cloud trial — set up as the [FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/) during the Solution stage. +5. **FlowFuse is available to test.** The customer has either installed FlowFuse (self-hosted) or signed up for a Cloud trial — set up as the [FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/) during the Solution stage. For a self-hosted install this is more than "installed": the environment must be able to reach the hosts FlowFuse needs — in particular to **install and update nodes and packages** — with any firewall change requested *and proven* before the PoV starts, not discovered mid-PoV. See [Networking requirements](/docs/install/networking-requirements/). ### PoV meetings diff --git a/nuxt/content/handbook/sales/meetings/solution.md b/nuxt/content/handbook/sales/meetings/solution.md index e6ef7bc52e..a2a4891222 100644 --- a/nuxt/content/handbook/sales/meetings/solution.md +++ b/nuxt/content/handbook/sales/meetings/solution.md @@ -57,7 +57,7 @@ that FlowFuse is an app platform rather than a way to run Node-RED. 2. **The apps that will solve it.** The app or apps are scoped against FlowFuse's [app delivery methods](/application-guide/flowfuse/app-delivery-methods/) and app patterns (above), so the PoV showcases FlowFuse as an app-building platform — not a test of Node-RED. One use case may take one app or several. 3. **Well-defined success criteria.** Each thing the PoV must prove is written as a concrete pass signal both sides agree on, so "success" is settled before testing starts. 4. **An agreed plan.** The tasks, owners and dates are agreed *with the customer*. -5. **A ready environment.** The customer is set up to test in a [FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/) — a Cloud trial or a self-hosted install. Its form follows the architecture decision above: where FlowFuse lives. +5. **A ready environment.** The customer is set up to test in a [FlowFuse Trial Environment](/handbook/sales/flowfuse-trial-environment/) — a Cloud trial or a self-hosted install. Its form follows the architecture decision above: where FlowFuse lives. For a **self-hosted** install, "installed" is not the same as "ready": the environment must also be able to reach the hosts FlowFuse needs — above all to **install and update nodes and packages** — or the PoV stalls the first time someone adds a node. On locked-down OT or air-gapped networks, get the required outbound access filed *and proven* here, in Solution, not during the PoV. Hand the customer's network team the [Networking requirements](/docs/install/networking-requirements/) list, and validate a real package install against it — some packages pull native builds from arbitrary hosts that can't be fully enumerated, so a working allowlist is the thing to confirm, not assume. These five outputs are the same five gates as the [Pre-PoV checklist](/handbook/sales/meetings/pov/#pre-pov-checklist): Solution's job