We're using visibility filters on our components as a way to show and hide components. If someone has a specific permission set, like "new feature pilot permissionset," we use that to show a component for those users.

We would like more flexibility in what we use visibility filters for. For example, we'd like to set an organization wide setting that says "this feature is now available for everyone." We'd like to be able to roll out a new feature to some users, then when it's ready, role it out to all users, without making a code change. The problem is visibility filters can only read from the current user or current record, so there's no way to check for something like "show this component if the user has this permission set, OR if this org wide setting is in place."

So what I'm wondering is there a way to write a global Apex controller, or global Apex middleware, so that every time a page loads, we dynamically add an attribute to the current user record, like their "available features," which we calculate based on org settings? Can we hijack all page loads and add something to the user object? Or could we do something like call and endpoint on all pages that modifies the user record in memory in Javascript?

Another potential solution to build this feature is to add a custom field to the user object, and when we toggle a feature setting, do a mass update to modify all users to set the appropriate flag. However I'd like to avoid the mass update route if there's a potential way to do it dynamically.

1 Answer 1


You can do it dynamically by harnessing Custom Permissions.

Define a Custom Permission in your org and gate component visibility on that Permission:

Screenshot of Permission setup in App Builder

As you test and roll out, assign the Custom Permission to one or more Profiles or Permission Sets for users who should have access. You can even define a Permission Set that does nothing but assign this Custom Permission.

Once your rollout is complete, simply set the Custom Permission on all of your Profiles, and every user will immediately have access.

  • This isn't ideal for our use case because we don't want to have to keep blanket assigning permissions sets to all users as we build features. That's an additional cleanup step later of removing the permissionset from all users after we remove the visibility filter from the code. We'd rather it be the opposite, a way to detect all users have the feature without having to modify all users (which is more common in feature flagging)
    – Andy Ray
    Commented May 31, 2020 at 22:03
  • You don't have to keep assigning permission sets. You can assign an arbitrary number of Custom Permissions to your existing Profiles and Permission Sets as features become part of your production setup.
    – David Reed
    Commented May 31, 2020 at 22:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .