Feature Requests

Grant admins universal permission to approve, deny, or cancel any pending change request.

Allow users to select specific individual approvers in addition to an enforced backup group.

Today, OPA policy evaluation covers the fme_segment package (segment create/update) but does not extend to fme_segment_keys, which is the package used when adding users/keys to an already-existing segment. This creates a gap: policy checks can be bypassed by growing a segment incrementally after creation, since there's no enforcement point once a segment is live. Ask: Add fme_segment_keys as a package covered by OPA policy evaluation, so that key/user additions to existing segments are subject to the same enforcement as segment creation — allowing customers to define org/project-scoped rules (e.g., blocking additions that would push a segment over a defined size threshold) rather than relying on a blunt account-wide cap. Customer context: Customer wants to cap regular segments at 100 keys to prevent teams from building oversized segments (10K–100K range) through the standard segment-creation flow, where they should instead be using the Large Segments feature (>10K keys). This is specifically about regular segments, not Large Segments.

Customer would like to have server side large segments

Today, moving an existing project into a different organization is only supported for the CI/CD module — it's not available for other modules like Feature Flags/FME. Once a project is created under an org, it's effectively stuck there. This is blocking customers who want to reorganize from a single flat org into multiple orgs (e.g., structured by line of business) as they scale. They can create new projects under the new orgs going forward, but have no path to migrate their existing projects over — meaning they're stuck running a split model indefinitely, or re-creating projects from scratch and losing history/config in the process. Requesting that project-to-org migration be extended beyond CI/CD to all modules, so customers restructuring their org hierarchy can move existing projects rather than being limited to new ones.

Currently, once a Change Request (CR) is rejected or resolved as failed, it moves to a non-mutable status and cannot be approved or reopened via the UI or API. If the rejection was made in error, or the CR failed due to a platform-side issue, the only path forward is submitting a brand new CR and running it back through the full approval process. For customers with formal internal change management processes, this creates friction when a mistaken rejection needs to be corrected quickly, since re-running an approval cycle can take significant time and blocks production changes in the interim. Request: provide a supported way to recover from an incorrectly rejected/failed CR without requiring a full new submission and re-approval cycle. Options could include: Allowing a rejected/failed CR to be reverted to a "requested" or "scheduled" state (with appropriate audit trail/permissions) A dedicated recovery/override endpoint or workflow for this scenario, separate from the standard approval flow Guidance or tooling for "cloning" a previously approved CR so it can be fast-tracked through approval Context: the current non-mutability rule exists because resolving a CR (approve or reject) unblocks further changes to the underlying flag, so reopening an old CR risks inconsistency with the flag's current state. Any solution should account for this and avoid introducing state conflicts.

Right now, finding out which flags need action (stale, aged out, awaiting approval, etc.) requires manually checking reports or building your own tooling — there's no in-product surfacing of this at the point where users actually log in and work. Requesting a "My Work" page module that proactively shows a user their own outstanding flag items — e.g., flags they own that are aged/stale and candidates for cleanup, flags awaiting their approval, or flags flagged by governance rules (naming, ownership, etc.) as needing review. Think of it like a personalized inbox for flag hygiene, surfaced right on login instead of requiring a separate report pull. This will help reduce the manual, email-driven process teams currently use to track down aged/unmanaged flags — putting it directly on "My Work" would make cleanup part of the normal login flow rather than a separate reporting exercise.

Today, OPA policies can be applied to feature flags (naming conventions, ownership rules, promotion gates, etc.), but there's no equivalent governance layer for segments. Segments can be created or modified freely, with no policy checks — even though they directly control who gets exposed to a flag or experiment. As flag governance matures, this becomes a real gap: a flag can be tightly policy-controlled while the segment behind it isn't. Requesting the ability to define and enforce policies on segments, similar to flags — e.g., naming/format rules, ownership requirements, approval gates before activation, or scope/size constraints on segment definitions.}

I want to be able to do Bayesian analysis in FME's warehouse native experimentation so our Product team does not need to rely on the Data team to do the Bayesian analysis for them. Most of our experiments are done with small sample sizes where frequentist methods are not practical, and hence Bayesian analysis is required.

Allow configuring the per-IP rate limiter for the FME API to accommodate use cases that require a higher-than-default limit but cannot spread requests across multiple IPs.