- docs
- FlowFuse User Manuals
- Using FlowFuse
-
- Getting Started
- Static asset service
- Bill of Materials
- FlowFuse Concepts
- Instance States
- Changing the Stack
- Custom Hostnames
- Custom Node Packages
- DevOps Pipelines
- Environment Variables
- FlowFuse Expert
- FlowFuse File Nodes
- FlowFuse MQTT Nodes
- FlowFuse Project Nodes
- FlowFuse Tables
- Groups
- High Availability mode
- HTTP Access Tokens
- Instance Settings
- Logging
- persistent-context
- Role-Based Access Control
- Shared Team Library
- Snapshots
- Team Broker
- Teams
- User Settings
- FlowFuse API
- Migrating a Node-RED project to FlowFuse
- Device Agent
- Device Agent
- Hardware Guides
- FlowFuse Cloud
- FlowFuse Cloud
- FlowFuse Self-Hosted
- Quick Start
- Installing FlowFuse
- Upgrading FlowFuse
- Administering FlowFuse
- Support
- Community Support
- Premium Support
- Debugging Node-RED issues
- Contributing
- Contributing to FlowFuse
Enabling Soft-Launched Features for Specific Teams
During a soft launch campaign, new features are gated behind PostHog feature flags and enabled on a per-team basis. This guide describes the process for enabling a feature flag for a specific team on FlowFuse Cloud.
Process
1. Change Request
A change request is created in the CloudProject repository. The request must include:
- The internal team ID of the team that needs the feature enabled
- The feature that needs enabling
2. Identify the Feature Flag Key
The developer or admin handling the request should know which PostHog feature flag key gates the requested feature. If unsure, ask in the Slack engineering channel.
3. Update the Feature Flag in PostHog
- Log into PostHog on the production project
- In the left-hand menu, navigate to Features > Feature Flags
- Find the relevant feature flag key in the list and open it for editing
4. Add a Release Condition
Under Release conditions, add a new condition set for the team:
- Click to add a new condition set
- Give the condition set a description — use the team or customer name for readability (see Organizing Condition Sets below)
- Add a filter:
team-id— equals —<given-team-id> - Set the rollout percentage to 100%
- Save the feature flag
5. Verify and Close
- Verify that the feature flag change is reflected on production/cloud — confirm the team now has access to the feature
- Once verified, close the change request in the CloudProject repository
Organizing Condition Sets
When adding release conditions, prefer one condition set per customer. If a customer has multiple teams, group them under the same condition set. This approach keeps things readable because each condition set can have a description identifying the customer, avoiding the need to track and correlate raw team IDs.
If the feature flag already has existing condition sets, follow the pattern that was established when the flag was first created. Use your judgement on the best approach — the goal is to keep the list of conditions manageable and easy to audit.
