# Using Access Groups for Conditional Visibility

At this point our discussions are focusing on two key use cases for Access Groups;

1. Conditional visibility of elements
2. Routing

## Modify Your Page by Access Group 

Currently, you can check for access-group inclusion by checking the array, e.g.; 

```javascript
user.access_groups.includes('pro');
```

{% hint style="info" %}
This technique is demonstrated in the [cloneable](https://webflow.com/made-in-webflow/website/current-user-info) to apply user access group info to attribute-tagged elements.
{% endhint %}

```html
<script> 
window.sa5.push(['userInfoChanged', 
  (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 'pro' access group.
      if(user.access_groups.includes('pro') {
        
        // Do whatever you want to your page
        
      }
    
      // Make changes to the page when the current user
      // is NOT in the 'pro' access group. ( notice the ! operator )
      if(!user.access_groups.includes('pro') {
        
        // Do whatever you want to your page
        
      }    
      
    }
    
  }]); 
</script>
```

## Conditional Visibility

This technique can be used with custom code to **hide**, **show**, **create**, or **remove** elements.

### Displaying certain elements only to users in a specific access group

> Let's suppose you have several elements that you only want to appear when the user is in an access group named `pro`, and you want those elements deleted from the DOM otherwise.&#x20;

Setup;

* Create a global class, we'll call it `access-group-pro` for simplicity.&#x20;
* Assign it to all elements that you want to appear only for your `pro` access group members.
* Set the style to display: none, so that it is initially hidden, until access group can be determined.&#x20;

{% hint style="info" %}
For this type of operation, [global classes](https://university.webflow.com/lesson/web-styling-using-classes?topics=layout-design#how-to-create-a-global-class) are quite useful since they can be applied on top of other class arrangements. Alternatively, simply wrap your elements in a DIV and assign your `pro-users` class.&#x20;
{% endhint %}

{% code overflow="wrap" %}

```html
<script> 
window.sa5.push(['userInfoChanged', 
  (user) => {
    
    // Check to see if access_groups info is loaded
    if(user.user_data_loaded.access_groups) {
  
      // Find all elements tagged [access-group]
      // and set the inner text to YES | NO
      const elements = document.querySelectorAll('.access-group-pro');
      elements.forEach(element => {
      
        if(user.access_groups.includes('pro')) {
        
          // If the user is in the 'pro' access group, remove our global class
          // this will make the element visible
          element.classList.remove('access-group-pro');
          
        } else {
        
          // If the user is NOT in the 'pro' access group, remove the element
          element.remove();
          
        }
      
      });
      
    }
    
  }]); 
</script>
```

{% endcode %}

{% hint style="warning" %}
**SECURITY:** if you are working with any form of *sensitive* data, this is not a means to secure that data. Even removing the element will not prevent prying eyes from finding it if they simply disable javascript and examine your page source.&#x20;
{% endhint %}

## Future Ideas

We're looking at adding conditional visibility support to  SA5's Data-Binding lib. Currently our thinking is this;

* Add two new attributes;
  * `wfu-bind-show` will display an element, only if its data-bound value is truthy
  * `wfu-bind-hide` will hide an element if its data-bound value is truthy
* Add a new internal binding resolver piece to the architecture which is source-aware. Regarding the User Object, it will resolve the `access_groups` array into a bindable boolean value.&#x20;

This would support attribute constructions like;

`wfu-bind-hide` = `$user.access_groups.basic`

With this you can make elements conditionally visible on the basis of a single access group.&#x20;

{% hint style="success" %}
The reason for both a **show** and a **hide** variant is that it allows easily for a default state.&#x20;
{% endhint %}

{% hint style="info" %}
Truthy basically evaluates in the same as JavaScript's truthy, however SA5 expands on this slightly.&#x20;
{% endhint %}

{% hint style="info" %}
In the future we may consider more complex specifiers like multiple groups with a boolean AND;

e.g. `$user.access_groups.basic+pro`

A boolean OR;

e.g. `$user.access_groups.basic|pro`

And check-modifiers like boolean NOT;

e.g. `$user.access_groups.basic+!pro`

However at this point you would handle these situations using custom code.&#x20;
{% endhint %}

Later, deprecate `[wfu-show-logged-in]` with an SA5 Data-Binding approach, e.g.

`wfu-bind-show` = `$user.logged_in`

## Routing

{% hint style="info" %}
This is a bit of a beefier design change as we've just built a routing engine as part of the upcoming Detect lib. We'd want to separate that into its own module and likely move it into SA5 Core. As a result, we need to design this piece carefully.&#x20;
{% endhint %}

Use cases;&#x20;

* On entry into any page, e.g. `/my-page` redirect the user based on their presence / absence from an access group.&#x20;
* Modify URLs and button links depending on a user's presence / absence from an access group.&#x20;

### Zoning

This feature would probably benefit from some concept of zoning as a part of the routing architecture, so that you can broadly group pages and elements into an access zone. This would work in conjunction with Webflow's current access-group gating.&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://attr.sygnal.com/sa5-user-accounts/get-logged-in-user-info/access-groups/using-access-groups-for-conditional-visibility.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.