Exciting Developments in Lightning Communities (now Experiences)

When I first migrated our legacy Salesforce Tabs + Visualforce Community to a Salesforce Lightning Community in 2019, there were a few areas that were cause for work around. I’m happy to say many of those things have been greatly improved just two years later. One of the beauties of Salesforce is the constant evolution (3x per year).

The Nav Bar

The Nav Bar two years ago was a problem. I was on a mission to create a combined Partner + Customer Community, which in many areas worked seamlessly with Audiences. Audiences is a way to show or hide components to specific audiences based on certain criteria: Location, Permission (think Custom Permission you can create and assign to a Permission Set – the possibilities are endless), User Profile, or User Attribute. Think a custom field on this one that you can yield to your will. There are many clever ways you can utilize audiences in your community to show the right content to the right users. Most importantly, not show users things they should NOT see.

One limitation when it came to audiences was previously the Nav Bar. You could previously only have one Nav Bar, so you had to use some clever tactics if you wanted to hide a tab, like Chatter Groups for instance, that everyone has access to see. The work around was to add an audience at the page level, so that uses didn’t see an audience they weren’t supposed to see.

This has improved recently, as you can now create unique nav bars for different audiences:

The improvement I hope to see in the near future is the ability to audience individual tabs within the same Nav Bar. Right now, even if only one tab is different, you would have to create all the tabs plus the additional ones in the nav bar variation, so you could see how that could still become quite cumbersome to manage changes.

The Tile Menu Component

I love the tile menu as it gives you a very sleek design declaratively. You are able to add images that fit your branding, but the previous limitation was that you couldn’t create variations. You would need another full tile menu on your page to manage. Now you can have variations similar to the Nav Bar which is a big improvement. I was able to add an additional tile for a specific audience with a variation. Of course, the limitation currently is also the same. You have to recreate the entire Tile Menu. Hopefully, a similar improvement will ultimately come for the tile menu as well to be able to assign unique audiences to individual tiles within the component.

The other improvement that was recently released for this component was the ability to change the look and feel. It was previously just squared off tiles, but I prefer the rounded edges as pictured above. There are also other tweaks you can make now to where and how your labels are presented.

Permissions

Previously, access to the Experience Builder was an all or nothing thing, so if someone had access to the builder, they could publish at will. Now, we have the concept of ‘Contributors’. You can assign certain users 4 levels of access to the Experience Builder.

Here are the definitions below from: https://help.salesforce.com/articleView?id=sf.networks_access_control_overview.htm&type=5

It is important to research permissions in the community closely and do thorough testing. Giving user the permission ‘Manage Experiences’ for example opens up the ability to change all your community topics, including Navigational Topics. This is not clearly defined in the definition of this permission. I call this out because you could inadvertently give someone a permission that gives them more than what they need to do their job. An untrained user could end up changing something that could affect your entire site without realizing it. You should only ever give just enough permissions for people to do their jobs.

What I would like to see in the future is the ability to give certain users edit rights to only particular components. That would enable you to have someone outside of the admin team manage particular components they are responsible for, without having to give them the keys to the entire kingdom.

Publishing Changes

Back in my day 😉 – when you published your community, your only option was to publish the entire community. Luckily, I was the sole owner of our community for the most part, so I didn’t have to worry about whether someone else had changed something else in the community recently that they didn’t want published. However, you could see how this could become a problem quickly, if you had multiple people managing config changes for the same community.

Recently, Salesforce introduced the ExperienceBundle. The ExperienceBundle is a metadata type that allows you to programmatically deploy sites using VS Code or other IDE. This also means you can deploy individual pages rather than always being tied to publishing the entire site when you’ve only changed one component.

You can find out more on this here: https://developer.salesforce.com/docs/atlas.en-us.communities_dev.meta/communities_dev/communities_dev_migrate_expbundle.htm

I’ll close this blog by just saying that I love the ever expanding suite of options in Salesforce Experience Cloud as there is always something new to learn. I am having a hard time breaking away from calling it Lightning Communities, so forgive me. See y’all again soon!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.