FilteringEnabled Property is Being Deprecated

Hi everyone!

In 2018 we made games with FilteringEnabled enabled the norm, dubbed games with it disabled “Experimental Mode”, and then ultimately removed Experimental Mode. Every game since then has run as if FilteringEnabled was enabled, even if the property was disabled. However, the property still exists and shows up in the Properties widget.

Starting with the 478 release of Studio on May 12th, the FilteringEnabled property under Workspace will no longer be displayed in the Properties widget. It will still be accessible by the Lua API until this version has rolled out to all platforms, at which point we will flip a setting to make workspace.FilteringEnabled always return true and ignore any attempts to set the property.

How does this affect me?

In almost all cases, it will not. All games already run assuming FilteringEnabled is enabled. If your game has workspace.FilteringEnabled set to true (the default), or all code is from later than 2018, then this will have no impact to you. What this may impact is games with legacy FilteringEnabled migrations.

For example:

if workspace.FilteringEnabled then

Currently they will run the else path for games that have not explicitly set workspace.FilteringEnabled to true, even though the game is already running as if it were enabled. Starting with this change, all of these scripts will begin running the first path. In all likelihood, this will actually fix games that are incorrectly operating under the assumption that FilteringEnabled is disabled, but it is a behavior change nonetheless, so we are announcing this in advance.

How can I tell if I have legacy FilteringEnabled migrations in my game?

Using the Find In All Scripts dialog in Studio (Ctrl/Cmd+Shift+F), you can search for FIlteringEnabled in “All Scripts” like so:


If it returns 0 results, then there is no action required on your part.

What do I do if I have legacy FilteringEnabled migrations in my game?

If you would like the correct code designed for FilteringEnabled games to run, then no action is required on your part. The script will now correctly determine the state of FilteringEnabled for the game once this change is live. However, since the property will never return false again, it is recommended to replace the migration with just the true path. In the example of

if workspace.FilteringEnabled then

then your script should now look like


However, if you would like to preserve the (likely broken) existing behavior of your game as-is, then remove the entire if/else branch and replace it with the contents of the second branch. In this case:


You can test that your game works in advance by enabling the workspace.FilteringEnabled property. If it is already enabled, then this change will not impact your game.

As a reminder, this change is planned to take place with release 478 on May 12th. Thank you!


This topic was automatically opened after 15 minutes.

This was definitely overdue!

FilteredEnabled is such a misunderstood concept by both newer and older developers that it hurts having to constantly explain that there is no “FilteredEnabled” anymore and that it’s always “enabled” - people still think this is the root to many of their issues! :upside_down_face:


The fact that FE is always enabled in the first place makes this all the more necessary. Why have a switch for FE when it doesn’t do anything?

It’s like trying to turn on the lights in your home IRL when the power is out.
EDIT: Since some people are confused by my post’s wording, I support this change. It’s honestly better for the development community.


Yeah it has been sitting there for quite a while. You’ve no clue how many times I’ve heard people say “FilteringEnabled can still be disabled, the option is still there”
Bye confusing checkbox, somehow I’ll miss you :wave:


What if it will affect custom chat and stuff like that?

The FilteringEnabled property is for replication filtering and is not related to text filtering. There is more information on the property here Workspace.FilteringEnabled


Your post’s wording is somewhat confusing. I can’t really tell if you’re for or against this change.

In case you’re against it, keep in mind that FE determines whether changes made from the client will replicate to the server or not. In other words, if hackers try to change/remove objects or properties in-game, it will only show that change/affect them on their screen, while the rest of the server can play in peace.

As already stated by OP:

The option to choose whether or not it’s enabled in your game is like, as you said, flipping a light switch in a house with no power. That’s why it’s being removed…


An end to an era. An era of asking “is FE on?” because it was a bit confusing still having the property there as well as experimental mode switches.

I’m really glad that things are much more consistent now.


It’s about time this happened, FilteringEnabled’ behavior has been disabled for I don’t know how long now. I don’t know why this isn’t removed all together. I get backwards-compatibility and legacy purposes, but I don’t think any game even has this anymore.

1 Like

Will this update affect the “this game isn’t working as intended” message?

1 Like

This message should have already have been removed. If it hasn’t, can you link a game that still has it?


(post withdrawn by author, will be automatically deleted in 1 hour unless flagged)


They don’t show up, but for which reason?

I mean if you wanted exploits to do server sided stuff with ease, then no FE would’ve been fine, but almost every developer can agree that FE has been the greatest game security update to get pushed out


This post was flagged by the community and is temporarily hidden.

1 Like

And having exploits delete the map is fun?


Good riddance. It’s funny the property sat there for so long.

Is there any technical reason why there needs to be a behavior change? Or is it just to be a nail in the coffin and try to coerce games that do this migrating into working?


Agreed, Roblox without FE is hard to imagine or recall now, a thing of the distant past and I am more than happy about it.

Good riddance. I honestly thought this would come far earlier. Three years after the fact is quite a great deal of time for something being rendered obsolete vs being formally treated as such.

I’m happy to see this change, and overall it should remove a useless speedbump newer developers might run into when trying to figure out what the property does.

Will this come with an alias for SoundService.RespectFilteringEnabled? It’s not too big a deal, but its name has less meaning with the removal of the corresponding property it relies on. As far as I’m concerned, a change like this is relatively useless, so it’s more a thing of curiosity than a request.