Restricting Access to Segments of your Support Center

Last Updated -

With Multi-brand, you can create multiple support center portals for different brands, products, or user types. You can then manage which topics and articles show per brand. You can also give each brand a unique Support Center theme or optionally share one theme across all brands. 

All brands are connected to your single account. If you use a private portal, you can choose which brands have Private Access enabled. For example, if you have a brand for your customers and a separate brand for your employees, you can disable private access for your customer-based brand and enable private portal for your employee-only brand.

What if you want private portal enabled for both, but want a different login process for your employee-only brand? Or what if you have multiple brands, and each has a completely different login system? What if you only want VIP customers to have access to a particular brand? Read on! 

Different login endpoints for different brands

While it's true you can only have one private portal configuration shared across all brands, you can develop your muiltipass endpoint to intelligently process logins across multiple systems.

For example, you can add "?brand=ABC Co" when routing users to your multipass endpoint. Then, within your multipass code, you can check for this parameter and ensure you're authenticating the user correctly and passing them to the correct brand once authenticated.  

Different logout endpoints for different brands

If your brands use different CNAMEs you want to hard-code the Logout URL in each web theme. The syntax is https://<cname>/customer/logout. The user will get logged out and end up on the home page of the current brand. If you want users of all brands to end up on the default brand you can populate the Logout URL field on the Private Access settings page with the URL to your default brand. 

Adding special access restrictions to certain brands

If you'd like to restrict access to a specific brand based on the customer's access levels, user type, products purchased, etc., you'll first want to set up a customer custom field. For example, "access_level", "user_type", or "products_purchased". 

Then, when you process the multipass login, you'll want to pass along the value of this field to Desk. If an employee logs in via multipass, you might send along "customer_custom_user_type" equal to "Employee".

With this in place, you just need to update your Support Center theme to evaluate what this custom field is equal to for the logged in user.

This example code would go at top and bottom of your employee-only brand's Layout section of the Support Center theme: 

{% unless current_user =nil or current_user.is_guest %}
  {% if current_user.customer.custom_user_type ="Employee" %}

    Continue rendering support center Layout
  {% else %}
    <scriptwindow.location = ''; </script>
  {% endif %}
{% else %}
    <scriptwindow.location = ''; </script>
{% endunless %}

This code first checks to see if the user is authenticated with multipass. If not, it sends them to your multipass login with a GET parameter that tells your login page the user is trying to access your employee-only brand. This way you know how to handle their login attempt (i.e., check the employees user table instead of customers user table). 

If the user is actually already logged in, the code then checks to see if they have the correct user type to access this brand. If they aren't recognized as an employee, it redirects them to your Support Center designed for your customers. 

Related article: Configuring your Support Center for Read-Only Access During Maintenance