Conditional Visibility Hacks Based on Access Groups

Has anyone come up with a hack to create conditional visibility on individual elements based on User Access Groups?

I’m trying to show or hide specific menu items based on a user’s access group.

For example, I have two CMS video collections called “members April 2023” and “members June 2023”. I also have access groups with the same names.

I only want to show the “members April 2023” menu items to the corresponding access group.

Any help would be appreciated. Thanks!


I’ve prototyped a solution for this but I’m quite busy with projects and I have not seen a lot of interest in this feature. If enough people are interested I might completed it and add it to the Sygnal attributes lib.

The big challenge is that there’s no way to secure “gated” elements using a client-side gating approach.

Have a look at the discussion here if you’re interested;

1 Like

Thanks @memetican. I would definitely be interested in this feature. We just decided to move our membership platform over to Webflow and this might be a deal breaker if I can’t figure it out. I’ve looked into Memberstack but I’d love to keep it all in Webflow if possible.

1 Like

Hey @joemuscatello , did you ever work out how to do this?

We ended up adding access group support to SA5’s user info lib for a client project.
Details are in the SA5 docs below.

If you need a much faster and more powerful solution, we have a new approach that gets the entire user info record instantly and allows you to personalize your site based on the current user’s access groups, custom user fields, etc. We use it most often when a client needs high-performance personalization features, “partially” gated content like an article preview, or tighter security controls like instant lock-outs. Drop me a message if you need to talk about a custom build with features like that.

1 Like

Hey Michael, I just learned about SA5 a day ago and what you guys are building is super sweet! Thanks so much!

I am currently working on a task of adding conditional CTA buttons based on user access groups, and so far, I’ve been able to successfully fire SA5 scripts and get the member’s profile data including their respective access group. However, I am now stuck when adding the hide and show attributes to these buttons.

Am I missing a step or script that is to be implemented on page or site wide for the attributes to work? Thanks in advance for any help you can provide.

Hey Edward,

You’d just use the userInfoChanged event to detect when access groups are loaded, and then you can do whatever DOM manipulations you like in JS.

1 Like

Hi, Michael,

I wanted to thank you for a great library!

I was able to implement the fully working POC in under 30 minutes as a no-coder. Most time I got stuck on the missing piece and that was for me the example of JS condition to remove some DOM element by CSS class.

Now I do it like this (with jQuery):

// Remove element by class name if user has free plan
if (user.access_groups.includes('free')) {

Maybe this will help somebody.

Or if there is a better way, let me know!

I am planning to refactor my implementation tmr and use also some other features of the lib, like showing user Name into UI etc.

On your note that you do not see much interest in this feature… I would think it is maybe a little bit more advanced for Webflow users, but it literally make Webflow much more usable and it saved my a** as there is no other option (for native users+ecommerce solution). So keep it up I believe much more users will come! :slight_smile:

All the best, Petr

1 Like

Thanks Petr, much appreciated.

I’ve added some more practical examples to the conditiona-vis by access groups notes, that you might find useful.

That’s good to hear. Yes I was a bit surprised actually, because access-group-specific UX design is one of the core capabilities we use on our own builds - however in our case security and performance are important factors so we build it using our Hyperflow reverse proxy framework instead, which can gate elements properly.

For most users of SA5, there is more interest in the personalization features like displaying the users name & photo, and tagging form submissions so that they are automatically connected to the logged-in user.

1 Like

Hi, Michael,

thank you for the DOC update. The setup with a global CSS class/es is sweet. I am going to try it right away :slight_smile:

Regarding security. OFC this is not comparable to server-side rendering. But, depends on the use case, this can be secure enough.

I have spent several hours testing and here is my 2 cents. Hope this will help others to decide.

First, lets assume today we can:

  • create Javascript only enabled sites (from user perspective, as there is <5% or less of users with JS disabled or missing feature)
  • except SEO content, where Javascript rendering can hurt or be difficult to implement correctly

I was evaluating following 2 use-cases:

  1. List of recipe ingredients:
  • the amount of ingredients is populated by Javascript from array, loaded from backend
  • the reason is I want to be able to recalculate the amount if user click + or - button

If JS is disabled:
SEO: OK, this data is not critical for seo
Security: OK, data are not fetched from array at all
So to use the feature, user has to not only disable JS but also tinker with data somehow to assemle them correctly, or maybe not disable JS but rather use Developer console to somehow bypas SA5 DOM manipulation… on wevery page, for every recipe,… this is beyond many users ability and patience.

  1. Rendering Vimeo/Vistia/… video
  • the player is fully Javascript dependent
  • they have many protection in place the user is not able to just download or stream the video without JS or withou proper auth

If JS is disabled:
SEO: OK, video not critical for seo
Security: OK, no video played

Another small obstacle I have added is a noscript element, which cover the whole VP and inform user about the need of enabled JS.

    <div class="noscript" style="position: fixed; top: 0; left: 0; background-color: rgba(0, 0, 0, 0.5); z-index: 999999; height: 100%; width: 100%; text-align: center; padding-top: 40vh;">
    <h1>This site is best used when you have JavaScript enabled.</h1>

This looks like this:

We will also combine this technique with server-side rendering based on logged state, so public rendering will be completely safe. AFAIK for my use case this is enough.

Have a great weekend!


Thanks again @memetican! I’m very limited in JS and I’ve tried making this work this without avail :frowning: but am confident that it can be done with SA5. Here’s the JS Code I am implementing before the /body of a page:

window.sa5 = window.sa5 || [];
  (user) => {
    // Check to see if access_groups info is loaded
    if(user.user_data_loaded.access_groups) {
      // Make changes to the page when the current user
      // is in the 'vendor-tier-1' access group.
      if(user.access_groups.includes('vendor-tier-1') {
        // Do whatever you want to your page
        const tierTwoButtons = document.getElementById('tierTwoButton'); = 'none';
      // Make changes to the page when the current user
      // is NOT in the 'vendor-tier-1' access group. ( notice the ! operator )
      if(!user.access_groups.includes('vendor-tier-1') {
        // Do whatever you want to your page
        const tierOneButtons = document.getElementById('tierOneButton'); = 'none';

Because this code is to work on three instances on the page, ideally this is to work on elements by Class instead of ID. Any insight helps! Thanks again!

Hey Edward, it looks like you’re headed down the right path.

I have no idea what your page structure is, or whether you’re getting code errors on your site, that’s where I’d start. Basic dev 101 stuff.

Yes you can use classes instead for your DOM selectors, or I generally use custom attributes for this, it keeps my programming and styling distinct.

Make sure you’ve setup SA5 access groups properly as well, or it won’t know what your access groups are.