ConfigService experiments currently only support split-based targeting (e.g., percentage rollouts or attribute-driven cohorts). This makes it impossible to explicitly include or exclude specific users by UserId, which is a common requirement for testing, QA, moderation, and staged rollouts.
Problem
Experiments today are well-suited for broad rollouts, but they fall short for controlled or operational testing:
Cannot target specific UserIds (e.g., developers, QA, trusted testers)
Cannot explicitly exclude known problem users
Cannot safely validate features with a fixed cohort before widening rollout
Forces developers to implement custom gating logic outside ConfigService
As a result, ConfigService experiments are often bypassed in favour of ad-hoc scripts or DataStore-backed allowlists, defeating the purpose of a centralized experiment system.
Current Behaviour
Experiments rely on:
Percentage-based splits
Attribute-based rules
No support for:
Explicit UserId allowlists
Explicit UserId blocklists
Deterministic membership for named users
Proposed Solution
Add UserId-based targeting to ConfigService experiments.
Example Capabilities
Allowlist specific UserIds
Blocklist specific UserIds
UserId rules evaluated before percentage splits
Example API / Behaviour
local snapshot = ConfigService:GetConfigForPlayerAsync(player)
if snapshot:GetValue("NewInventoryUI") then
-- experiment enabled for this user
end
Configured in the Experiments UI as:
“Include UserIds: [12345, 67890]”
“Exclude UserIds: [54321]”
Fallback to percentage split if no match
Benefits
Enables safe internal testing without shipping code changes
Allows deterministic QA and developer access
Reduces custom gating logic in production code
Aligns experiments with real operational workflows
Non-Goals
This is not a request for general user list storage
This is not a replacement for DataStores or moderation systems
Scope is limited to experiment targeting logic
Explicit UserId targeting would make ConfigService experiments substantially more useful for real-world development and live operations, without undermining existing split-based rollout mechanisms.
That’s just bloat for an engine that adds no value; don’t make Roblox become a Unity.
Attributes exist.
PlayerGui exists.
The rest is for you to implement.
ConfigService experiments already exist as a platform-level feature for controlled rollout and evaluation. The request is narrowly scoped to improving targeting within that existing system, not introducing new abstractions for gameplay state or permissions.
Attributes and PlayerGui are runtime mechanisms. They still require:
custom gating logic,
code changes for cohort management,
redeploys for simple tester inclusion/exclusion,
parallel systems that sit outside the experiment framework.
Explicit UserId targeting adds value precisely.
This is not about turning Roblox into Unity or adding engine bloat; it is about closing a gap in an already-shipped service so developers don’t have to re-implement the same allowlist logic repeatedly, inconsistently, and outside the tooling Roblox is actively encouraging us to use.
If the platform goal is to centralise experiments and feature rollout, then UserId targeting is a pragmatic extension, not excess complexity.
That called feature flags & you are reinventing them
This can be replicated by copying local script to PlayerGui from server.
Same effect but no bloat.
ConfigService is Roblox’s feature-flag method. This request does not reinvent feature flags; it addresses a limitation in how they can currently be targeted.
Copying LocalScripts into PlayerGui from the server does replicate the effect, but it bypasses the experiment system entirely and introduces several trade-offs:
Targeting logic becomes distributed and bespoke, rather than centrally defined.
Cohort membership is no longer observable or auditable in the ConfigService tooling.
QA and staff access require code changes or server-side branching, not config updates.
Rollouts and analytics are decoupled from the mechanism that actually gates the feature.
From an engine perspective, this is not new functionality—it is consolidation. Developers are already implementing UserId allowlists for experiments; they are just doing so repeatedly, inconsistently, and outside the platform’s intended workflow.
The proposal keeps:
feature evaluation in ConfigService,
rollout logic in ConfigService,
code paths simple and declarative.
The alternative works, but it shifts responsibility onto every developer to re-implement targeting that the platform already partially owns. Adding explicit UserId targeting reduces that duplication without changing how features are consumed at runtime.
