On my way to New York for a launch event for a 6,800 person employee community that we just rolled out, I opened up the release notes for the Summer ’17 release to check out what’s coming for Communities in the next release. I was looking for a specific feature that Salesforce product management had said was coming, and it took me forever to find it, because there are so many new things for Communities this release and many of them are pretty large in scale! It’s a very ambitious and exciting release frankly. I figured I’d summarize the top items that I’m most excited about this release from a core platform perspective, so if you don’t have a lot of time to read the release notes yourself, you’ll be aware of the most critical updates that have the most far reaching impacts.

1. Automatic Topic Assignment for Articles – this is by far the most important feature in the release in my opinion. Why? Every customer using Lightning Communities with articles needs this feature as the Community Builder templates use topics to group articles, not data categories. Up until now, knowledge authors would set the data categories on an article and a community moderator would manually need to go into Community Workspaces to assign topics to that article based upon the data categories selected by the author so that it would show up everywhere expected in the community. Every customer we worked with on a customer or employee community who used knowledge wanted this feature automated, so that the topic assignment would be instantaneous when the article was published, avoiding a time delay in assigning topics and a manual process that could be error prone. I’m really excited to see this feature get released and to see the flexibility built into it.
2. Upgrade Community Licenses – We’ve been wishing for this feature for years, since the days of Salesforce Portals, and we’re thrilled to see it come. Let me explain this one, because it’s not obvious to most at first. Basically, if you created a user in a high-volume license (e.g. Customer Community license), you couldn’t ever upgrade that user into a role-based license (e.g. Customer Community Plus or Partner Community license). Rather, you had to deactivate that user and then insert a new user from scratch, then migrate all of their records they owned to the new user. Chatter posts couldn’t be migrated, so users would lose credit for things they’d posted in the past. Now, you just have to update your users profile; no new user or data migration required. It’s worth calling out that you can’t go backwards (from a role-based license to a high-volume license), but that is not a common use case so I don’t think it will impact many companies.
3. Integrate Custom Apps into the Chatter Publisher – This is another pilot feature and it is definitely the most revolutionary of the features I’m highlighting this release.  This feature allows app developers to build a feature that mimics the way you might attach a file to a Chatter post. I’ve worked with a lot of 3rd party apps that today have had to build a custom component to enable users to post something from that app into Chatter, which isn’t very seamless and takes users out of the context of where they are posting. This feature allows you to stay in-context and to really take Chatter to the next level. There are really endless possibilities to what you could do here. I know that ViewTrac, a Force.com video solution, are planning to take advantage of this to enable users to embed videos in Chatter, a common request in many different kinds of Communities. I could also see this feature being used to gamify the community and enable custom badges to be created / assigned.

There are a lot of other very exciting features in the release, like a Partner Community template (which really deserves a blog in and of itself since it’s such a big feature), and some of them may excite you even more than my above selections. You should definitely check out the release notes when you have a moment, because this is just scratching the surface of all of the features that are headed your way in June!

The Salesforce Summer ’17 release has a lot of features for Community Cloud that are centered around having a more targeted, intelligent experience for your community members. As part of this, Salesforce is tracking more interactions than ever and giving you (and Einstein) access to that data to take action on it. Here are a few highlights:

1. Community 360 is a new pilot-only feature that allows you to capture information about what articles a customer looked at before submitting a case and expose that to support agents, so they don’t make the mistake of sending a customer something that they already looked at and determined doesn’t solve their problem. This kind of insight is invaluable for shortening case duration and increasing customer satisfaction.
2. Criteria-based Audiences allows you to offer different experiences to different users based upon criteria such as profile, IP address, and now in Summer ’17, by city and domain. Creating nuanced experiences for different types of community members based upon their role or location allows you to serve them more relevant information, improving their community experience.
3. Filter by Unread Posts allows your community users to filter their Chatter feed in Groups to only see posts they haven’t yet seen. I see this as an extremely powerful feature for group moderators who need the ability to stay on top of what is happening in their group. This filters out the noise of posts they have already seen and enables them to quickly get caught up on conversations they have missed.
4. Analytics are getting even better with the Service Community Scorecard. Access to viewing click-thru rates on related articles helps you improve your content creation strategy. The scorecard also helps you identify who is a champion versus a casual observer through participation reports.
5. Short-staffed and don’t have time to look for spam? No worries. Einstein has your back! In this pilot feature, Einstein will automatically flag posts that it sees as spam. As a community moderator, you’ll get emails whenever a post is flagged. I think this kind automation is going to truly enable community managers to focus more on strategy and less on tactical tasks like moderation.

I’m personally really excited by the focus on capturing interactions and then making it easy to take advantage of this data in use case-specific, bite-sized pieces instead of simply opening up an API with every single community member’s activity logged there and having customers figure out what to do with that data.

A Functional Perspective on Community Design

Architecting reusable lightning components for a Lightning Community is very different from architecting a Visualforce page. A key value proposition of Lightning components is that they are reusable and can easily be added into Lightning Communities by system administrators. In order to realize that value, it is critical to architect them for scale.

In my opinion, here is what you are striving for your system administrators to be able to do after developing your custom Lightning component, written in the form of the ubiquitous user story: As a system administrator, I can go into any template-based community to easily drag-and-drop Lightning components onto anywhere on the layout, configure attributes on those components to ensure they meet business needs and publish those changes without ever speaking to a developer to reduce the cost of developing and maintaining communities.

Now that we’ve established what we are trying to achieve, here are the top 5 things to consider when designing a lightning component for a Lightning Community:

Think about what is likely to change over time and make those into attributes 

After doing so many communities projects, you start to see trends in the kinds of things that end users request to change once you go live, such as component titles and the number of records shown in the results. A custom attribute is something that system administrators can configure for that instance of the lightning component inside of the community. For example, when designing the Ask Button component, Salesforce architect would have asked themselves what about this is likely to be custom from customer to customer. The text shown on the button is likely to be variable from business to business, so they made button label a configurable attribute.

Pro tip: If you ever go to translate a community into another language, if you control the text shown on the component in the Community Builder through a custom attribute, you can translate it in the builder versus going to custom labels. It’s much easier to deploy than custom label translations. Don’t know how to deploy a Lightning Community? Check out my blog on how to do this.

Ensure nothing is hardcoded 

This may sound like a no-brainer, but it is so critical that I’m going to state the obvious. While you may be building a component for a community you are launching now, a few months or years down the road, you may launch another community. Every Lightning component that you create custom in your Salesforce org and make visible to one community will be visible in the community builder of all communities, and it should seamlessly work in any community. From a back-end perspective, this means that your component is inheriting the CSS from the community builder using tokens and that you are using the $site.prefix tag to pull in the base community URL (e.g. mycompany.force.com/communityname/). If your component directs users to a custom page in the community, make the page name a custom attribute so that in one community the component can point to a page called ’news’ and in another community it can point to a page called ’newsfeed’, for example.

Before developing multiple similar components, try to get there with just one

The fewer components in the community builder, the easier it is for system administrators to find what they are looking for. Often, you will get requests for similar components that could be grouped into a single component. We recently had a customer who wanted to show the top 6 articles on their home page formatted with one set of styles and another page with the top 10 articles formatted with a slightly different set of styles. What we did to achieve this is create an Article List component that had 2 attributes:

• List Style
• # results to show by default

Take a look at the Salesforce ‘Feed’ component and look at how many different kinds of feeds that they’ve packed into a single component. This is what you’re striving for.

Define what should happen if no results are found 

If there is no data returned in your Lightning component, do you want to hide the component, show “No Results Found” or does it depend on where you are using the component? You will notice that with most of the native Salesforce lightning components in the Community Builder, the components will not render it if there is no relevant data, which will make the page load faster and keep the noise on the page down. You may want to introduce some kind of “Collapse if no results found” attribute to the component if you think that sometimes you’ll want to hide the component and other times show a ‘No Results Found’ message.

Put on finishing touches to make it admin-friendly

When you first create a Lightning component, if you do nothing, it will show up in the builder with the developer name. With a single line of code in the design part of the Lightning component bundle, you can give it a user-friendly name that will show up in the builder, helping your system administrator to understand what the component is. You can also give it a custom icon in the builder to help distinguish it visually from others; for example, Salesforce has given unique blue icons for all of their Feed-related components and unique green icons for all of their Content-related icons. Finally, don’t forget help text on the custom attributes that you introduce so that system administrators understand what those attributes are for and how to fill them out without needing to look at a separate how-to guide. For more on how to do this, check out this helpful guide.

Certainly, the above list is not exhaustive but offers you a starting framework to think through how to approach architecting your Lightning components. Remember to take advantage of custom attributes but don’t create too many that it becomes confusing or onerous to configure. If you’re looking for more guidance, spend some time looking at how Salesforce has architected all of their out-of-box components and notice the kinds of things that they have selected to make into configurable attributes and the things that they have not. This should help you think through the kinds of attributes you might want to create in your own components. As always, if you have questions or comments, post them below!

Yesterday Salesforce announced the launch of Lightning Partner Communities, delivering a best-in-class digital experience for companies looking to accelerate channel sales from their partner ecosystem. Empowering your partners, resellers, and channel teams with new collaborative tools has become imperative to driving growth for successful partner programs today. However, many companies still struggle with disconnected business systems, processes, and a standardized means of communicating with their partners. As a result, partners become disengaged and channel sales likely suffer.

If you’re in the market for a new partner portal to help accelerate channel sales or to provide a more flexible and dynamic partner experience, here are 5 reasons why (and features) you’ll fall in love Salesforce’s new Lightning Partner Communities.

1. Community Builder Templates – The future of Lightning Partner Communities is all about the templates! In a recent Community Cloud blog I wrote, I talked about the numerous advantages of building a community using the Community Builder Templates. For channel teams managing a partner portal, ease-of-use and empowering the business to manage the community (instead of going to IT for small changes) is one of the top business drivers for investing in Lightning Partner Communities.
2. Lightning Components – Beyond the templates themselves, Salesforce’s investment in Lightning continues with the use of Lightning Components for communities. The drag-and-drop capabilities of Lightning Components allows your channel team or community manager to configure or update a community without the assistance of a developer. In short, using both the Community Builder Templates and Lightning Components, you can significantly cut down the time to design and stand up your partner community. In a recent Lightning Partner Community we built for a high-tech company, we shaved off 2-3 weeks of development time using Salesforce’s native components to design their community experience. That development time equated to considerable cost savings that could be allocated to other Salesforce initiatives.
3. Mobile Responsive – One of the biggest requests or complaints we hear from our Salesforce customers looking to build a partner community, is the need for a mobile responsive solution that allows their partners to have access to all the information, materials and experts they need to manage their business on the go. Not having a user experience that’s optimized for mobile devices is one of the biggest downfalls of many legacy partner portals. Because the Community Builder Templates are fully responsive out-of-the-box, it’s easy to provide a rich experience that can be viewed on any mobile device.
4. Community Translations – If you have a global partner program like Equinix does, and there’s a need to display content in your partners’ native language(s), another advantage of using the Community Builder Templates is the ability to quickly translate your community using the Translation Workbench. Equinix had evaluated using Visualforce inside of Community Cloud, but the cost to move their prior standalone partner portal into a Visualforce-based community would have been very costly and time-consuming to do. With the Summer ’16 release, we approached them with a more cost-effective solution using the Community Builder Templates to accelerate speed-to-market, which included localizing community content in six different languages.
5. CPQ for Partner Communities – There are many perks to having your community centered around your business processes and your CRM. In addition to the connection to accounts, leads and opportunities, you can now enable your partners to work alongside your sales team with quotes to customers. Salesforce CPQ for Communities offers self-service price quotes giving your partners a one-stop-shop for everything they need to close business for you.

We’re not just excited because of what could be done, we’re excited by all of this due to what we have already done and continue to see be successful for our clients. Prior to this formal announcement from Salesforce, we delivered two template-driven Lightning Partner Communities, one for a long-time customer of ours who had a partner community built on Force.com that we built originally for them in 2013, right after the original launch of Community Cloud, and wanted to move to an easier-to-maintain, mobile-responsive solution, and other for Equinix, who was on a legacy standalone application. They were dealing with third-party integrations and the inability to scale their existing portal solution. If any of this resonates with you and you’re looking for more information on getting started with Lightning Communities, consider downloading our guide to channeling the power of partners with Salesforce.

Sam Jacobs, partner engagement manager, from our customer OpenX spoke about the self-service community that we helped them to roll out last October. They programmatically connect sellers of ad space and buyers of ad space in real-time. They are selective about who they let into their marketplace, they are ranked #1 in traffic quality, outranking even Google. They have 1200 publishers and 34,000 advertisers, and these numbers are quickly growing. With fast growth,

The idea of launching a community originated with Tish Whitcraft, the CCO at OpenX, who had previously launched communities at other companies and saw the value of communities in delighting customers. Previously, they had a simple customer portal and they wanted to offer their customers with something more. More and more customers are turning to social media to seek help and voice complains. They want something social and collaborative, not just transactional. They sought to blend both social and collaborative, and transactional. It wasn’t about cost savings. It was about delighting their customers. They thought about what makes for a superior customer experience. Providing a space for end users to interact with OpenX and each other. Convenience was also key; it needed to be mobile-responsive and intuitive. Transparency was also important; they didn’t want to hide the site behind a login like they had with their customer portal.

They recently launched Chatter groups to increase engagement. They are seeing growing page views and an increasing member base month over month. They have delivered one community-sourced idea in the last 12 months and have two more in progress. They attribute the success to ideas; this tactic was so successful because it gave them a stake in their business in their product and they feel like they have influence over something that affects their day to day. This fosters the intrinsic motivation for customers to keep coming back.

It’s about reinforcing your existence and ensuring there is a clear value proposition with your user base. Struggling communities tend to have an awareness issue, either they don’t know you exist or they haven’t visited you because they don’t understand what you have to offer them. Ensure you let them know what behavior your community replaces.

OpenX Lessons Learned:

Content Counts – if you only have transactional or support-heavy conversations, people will only come there and engage in those kinds of conversations. You need to start the conversations that you want your members to have.
Align Business Goals with Member Needs – understand where your business goals align with what your customers need, and deliver that.
Adoption Starts from Within – make sure your employees understand the value of your community. If your employees don’t use it, your customers won’t either.

Laura Walmsley is the Chief Business Development Officer at Preventure. They support 1.2 million people in living a healthier live. Using smart content and serving it up in a personalized way will help drive healthier habits and by linking personalization with community, can really drive behavior changes.

Their community serves over 1m people from corporate America today. They have steel workings and people leading the digital revolution, and a wide range of ages and health issues, from people looking to run their first marathon to those who are struggling with diabetes. Their goal is that 90% of their members improve their health every year. A person is 37% more likely to become obese if their spouse is obese. You are 57% more likely to become obese if a friend is. The inverse is also true.

Meet Maxwell is their wellness app (short for Maximum Wellbeing). Once you’re in the experience, you can serve up a personalized experience within the app. Users can upload a photo to inspire them, track their mindfulness minutes, track their glucose levels and the amount of sleep they are getting. The connect layer of their community is a tailored version of Chatter; they allow people to build teams in their workplace and to build and join groups meaningful to them. They can earn rewards and rewards spark change. They linked Meet Maxwell to marketing cloud to let customers know how their employees are doing.

I’m going to make a bold statement: Force.com Communities are a soon to be a thing of the past. With Winter ’17 bringing the final missing features to the Community Builder templates, it’s time to rethink the reasons why you said no to the Community Builder a few months back, and revisit templates. We’ve built dozens of Force.com Communities over the last 3 years (and many more portals and Force.com sites before Salesforce Communities was released in Summer ‘13), but I’m not at all sad to say goodbye to them at all because the Community Builder is now officially a superior way to create and manage your community.

The Advantages of Using Community Builder

I spend a lot of my time on sales calls with customers who are determining how they want to build their online community. A year ago, when Community Builder went GA in Winter ’16 release, I could only really recommend using the Community Builder to customers looking to launch public knowledge bases, self-service or engagement-centric communities with somewhat flexible branding requirements. The minute the community needed to have pixel-perfect branding designed by an agency, or bring in any Salesforce object other than cases, we had to use Visualforce. Major brands like Nokia and Ancestry.com were early adopters of this new technology, finding that it significantly accelerated speed-to-market for a self-service community solution, and lowered the long-term maintenance. Some customers joke that we’re being put out of a job since they need less of our help after go live, but personally, I think we are able to add more value helping our customers with more strategic Salesforce initiatives rather than helping with ongoing support. So those of us who architect the communities are actually thrilled to see this change since it means we focus on more interesting work.

As a plethora of new features were rolled out in the Spring ’16 and Summer ’16 release, my tone towards templates evolved as the tool did, and I was able to recommend the Community Builder to more customers. New features allowed users to leverage almost any Salesforce object that you wanted in the community and return it in search results. If we could not do something using the native Lightning components that Salesforce offered, we found using custom Lightning components was the perfect solution. Yes, there were some caveats (e.g. branding still was limited), but there was a lot you got with it natively like CMS-functionality, mobile-responsive templates and a library of pre-built Lightning components that you could drag-and-drop in place, so customers were willing to accept those limitations.

The Future of Community Cloud for Customers

As a well-respected solution provider and Community Cloud Ambassador, I’m privileged to work directly with product management getting clear visibility to the product road map to understand where future investments in Community Cloud will be (hint: it’s focused around the Community Builder). This allows me to use the 80:20 rule with customers who are on the fence. “The Community Builder templates have 80% of what you need today and the 20% you want is coming. And did I mention that building this in the Community Builder is going to be a small fraction of what you would pay for us to build it in Visualforce?” As you might imagine, this gets a lot of customers attention.

Thanks to all the investments that Salesforce has made in templates, it has been months since we sold a Force.com Community project. This summer, we have been working on two partner community projects that used the Community Builder, something that would not have been possible before the Summer ’16 release. However, there has been something missing for our customers that they agreed to go live without, reports and dashboards, because this are being delivered just a few weeks after they go live in the Winter ’17 release. Dashboards in Force.com communities were not designed for mobile, but in templates, they work beautifully.

While mobile-responsive reports and dashboards are great, I think the biggest feature in the Winter ’17 release is the ability to brand your community exactly how you want it with a Custom Theme Layout. What this basically means is that you now can build that pixel-perfect, agency-designed community that reflects your brand and doesn’t feel exactly like all of the other templates built on the Napili template (which, as a side note, has been renamed in Winter ’17 as the “Customer Service template”). This is truly the nail in the coffin for Force.com Communities, because now you can basically build a fully mobile-responsive community that reflects your brand perfectly, pull in any data that you want from Salesforce and build it faster than you can in a Force.com Community. 

Want to learn more about building a self-service community for your customers using Salesforce? Download our new guide below to explore the core elements of creating an exceptional customer service experience using Community Cloud.

Save

Save

It is clear that the Community Cloud product team has been busy the past few releases and the Summer ’16 release is no different. If we had to say that there was a clear winner in this release from a Community Cloud perspective, it would be community managers. Summer ’16 includes a number of robust moderation features for community managers that we think represent a huge leap forward in functionality, all in one release. Here are our five favorites:

• Improved Moderation Rules – Previously, moderation rules applied to all community members so you could not have different rules for internal users versus customers. Now, you can create a vast majority of different member criteria to define different audiences to target with different rules. For example, you can create groups based upon user type (internal, customer or partner) or based upon profiles. From there, you can even drill deeper to target based upon if that user just joined the community in the last X number of days or if it is their first post.
  

  Sample Member Criteria

• Pre-Moderation (BETA) – Do you want to approve posts before they are visible to the rest of the community? Now you can! For example, if someone mentions your competitor, you might want to flag their post for pre-moderation before making it visible to the rest of the community. To do this, determine which members this rule should apply to and which posts it should apply to. The next enhancement, Actionable Insights, makes it easy to approve all these posts en masse to make them visible.
• Actionable Insights – Insights (renamed “Engagement“ in Summer ’16) allow community managers to review lists of community member’s activity to help them moderate the community. Examples of Insights, or Engagement, could be a list of new community members, questions asked in the last two days without an answer, ideas voted on this week, and so much more. Until now, in order to take action on an insight, you had to click to go to the record in the community. Now you can select to take an action on up to 100 records at a time, such as approving posts that have gone through pre-moderation to make them visible in the community, deleting posts (e.g. from a spammer), freezing or unfreezing users and so much more.
• Freeze Problem Members – Today, if you have a community member with a behavioral problem, there is no way to temporarily remove their access to the community while you talk to them about their actions and judge if it is appropriate to reinstate them as a member. When Summer ’16 release goes live, you will be able freeze users in the click of a button from their user profile inside of the community, which will block them from logging in.
• Protect Your Community from Spammers with Rate Limiting Rules – This may be the feature most likely to save community managers hours of cleanup work if you should be the unfortunate target of a spam attack. Essentially, if someone posts X number of times within X minutes, you can automatically freeze the user or notify the moderator for further investigation. Salesforce’s own documentation of this feature is so spot on, that if you want to know more, be sure to read the full release notes.

Which of these are you most excited about and why?

As a Salesforce consultant, I rarely expect my French major to come in handy. Today, I put it to good use as I went to test out translation features in the Community Builder, known in French apparently as the “Générateur de communauté”, from inside the Winter ’16 Napili template. Here is what I learned:

You can translate template-based communities into many other languages.

To do so, go into the Site.com Studio and select the languages you want in the Site Configuration from the following options:

• Chinese (Simplified)
• Chinese (Traditional)
• Danish
• Dutch
• English
• Finnish
• French
• German
• Italian
• Japanese
• Korean
• Norwegian
• Portuguese
• Russian
• Spanish
• Swedish
• Thai

Once additional languages have been enabled in the Site.com Studio, you will see a language picker appear in the Community Builder toolbar. By toggling from English to French, I am able to update the properties of the pages and lightning components to be in French. If I toggle back into English, I see the English version of those pages and lightning components. For example, I can rename my home page to ‘Accueil’ and the ‘Ask a Question’ button to ‘Posez une Question’. If you are building a community in a language you do not speak, expect to create a list of all labels to translate and pass it to a translator.

Home Page in English

Home Page in French

It is recommended to create one community per language.

While you can translate all of the metadata (labels, topics, moderation criteria), if you mix languages in a single community, the data itself (e.g. conversations being had by the community) does not translate. This can make for a poor user experience. For example, if someone posted a question in Japanese, a language I regretfully do not speak, I would see their post in the community but not be able to make sense of it. Instead, build one community, clone it to create one for a different language (learn how in my last blog), enable the desired language in Site.com and then translate the template’s metadata. By having separate communities, each moderator has a unique place to manage their topics, recommendations, reputation levels and moderate the conversations happening in their community. It also gives flexibility for regional variation in layouts, images, topics and subtopics, data category access, etc. You may use different imagery to appeal to an audience in Japan than in the United States, for example, or may not offer the same products in all regions.

If you have good reason to create one community for multiple languages, it is definitely possible to do but takes a few more steps to setup. You will need to:

• Translate topics in the translation workbench
• Translate reputation level names in the translation workbench
• Translate user messages for moderation rules in the translation workbench
• Translate the navigation menu in the translation workbench
• Use a Visualforce email template to welcome new Community Members in their native language
• Create a custom channel for each language to allow community managers to allow you to target recommendations to users in their language. You’ll need to write code to add new users to the channel through the API.

Other things to remember if you are thinking of doing a single community for multiple languages:

• Each community sends the welcome email from a unique email address
• Each community sends the Chatter email with a single company logo and single, mailing address in the footer
• Users who have not logged in will see the community’s default language upon arriving at the community and can use the language picker to change into a different language. So if a Japanese user navigates to your community that is translated into English and Japanese, but the site’s default language is English, they will see the English version of the community and can switch over to Japanese using the language picker. Once a user is logged in, they will see the language indicated on their user record and the language picker is no longer visible.

Have other questions on translating your community? Post them here as comments!

While you can create a Salesforce Community using the Community Builder directly in your production environment, I would not recommend it in the majority of cases. Fortunately, it is quite easy to deploy your templates into production by following these three simple steps:

Step 1: Use Change Sets

Use change sets to move all custom lightning components you are referencing in the community from the sandbox to production, as well as any metadata that you set up outside of the Community Builder (welcome email templates, workflow rules, profiles, permission sets, etc).

If you skip this step, it will still allow you to deploy the community and will appear to be successful, but you will see an internal server error in the Community Builder and will not be able to make any updates until you have moved the missing components into production.

I highly recommend creating a deployment template and filling it in as you build your community to ensure nothing is forgotten at the time of deployment; it is an important part of our methodology at Perficient and ensures smooth deployments.

Step 2: A Little Navigation

From your sandbox, navigate to the Site.com Studio and locate the toolbar. Click the arrow next to the widget icon and select to ‘Export This Site’ from the sandbox. Then go into production and create a new community, selecting the same version of the template; going from a Spring ’16 Napili template in sandbox and moving Winter ’16 production environment will not work. You need to go from Winter’ 16 in sandbox to Winter ’16 in production. All customization performed inside the Community Builder will move over

Step 3: Update Admin Settings

Go to the Community Management console and update your administrative settings, topics, moderation criteria, etc. as these do not carry over automatically.

You can use this process to move the community between sandboxes doing the same thing, if a multi-step deployment is part of your change management process. You could also use it to effectively clone a Community, as well.

You may want to do this if you are looking to create a similar community with different users. For example, you might want to have a separate community for French users that looks like your English community, but does not mix French and English conversations in the same community as that can be confusing.

Spring ’17 Update: The navigation inside of the builder has changed since this blog was originally written. To get to Site.com Studio from the builder, you now need to go to Settings > Languages > Go to Site.com Studio Languages.

Summer ’17 Update: Salesforce has introduced a way to move communities between orgs using change sets. For more information, please review the Summer ’17 Release Notes.

Winter ’18 Update: Try following our proven framework for setting up a Salesforce Customer Service Community with the interactive workbook below.

If you have not yet had a chance to read the Spring ’16 release notes that came out yesterday, go read them now and skip right down to the Communities section because the Spring ’16 features are truly game-changing for Salesforce Community Cloud. After reading through the release notes yesterday, I emailed one of our customers, Sam Jacobs from OpenX who recently built a self-service community on the Napili template, a list of some of the features I thought that her company might want to leverage. Her response? “Wow. They’re all great, but some of them are kind of game-changing. I now have 23 reasons to be thankful this holiday season!” A colleague of mine and fellow blogger, David Wickland, who does web design for Salesforce Communities called it “a dream come true.”

So what’s so game changing? Imagine that you will now be able to create a community that can be customized to almost the same level as Force.com Sites Templates, except that now it has CMS capabilities to enable community managers to “own” the solution instead of your Salesforce developers. With so many out-of-box Lightning Components that you can drag-and-drop onto the pages, it is faster to implement and easier to update. Here are some specifics of what the Spring ’16 Community Cloud release will enable you to do:

1. Transform the template to reflect your brand. I have heard a lot of customers hesitate to use the templates because they did not look enough like their website. With Winter ’16, you could create custom pages, but they had only two layout options, 1 full-width column and 2 columns with a 2:1 ratio, and there was no way to update the layout of the native pages without overriding them with a custom page. Now there are 8 possible layouts and you can update the layout of native pages to use any of these, meaning your home page (or any page for that matter) can look any way you want it to.  You can also disable the native Napili header and put in your own header and navigation (e.g. if you want to use your corporate website header and have a drop-down navigation), and overwrite the native styles with Custom CSS. Essentially, you can strip the Napili template down to a blank slate and fill it with any Lightning Components and styles that you want. If you are building any kind of community and currently are not planning to use the Community Builder, you need to stop and seriously re-evaluate if that is the right path.
2. Optimize your community for SEO. Marketing executives will jump for joy with this Community Cloud release. There are several new features related to SEO in Spring ’16; first, you can now access the <head> tag in the community, allowing you to add SEO meta tags. You can also use this feature to add Google analytics tracking code, external JavaScript files and third-party libraries, and custom JavaScript blocks. Second, with the enhanced page management features, you can now add a page description for improved SEO.
3. Leverage more components with more flexibility.
   

   Leaderboard Lightning Component

   This release, existing components were made more flexible by allowing administrators to set more parameters on the components to customize them to meet your needs (the leaderboard component is a prime example of this) and many more components were introduced, such as a several different Chatter feed components that have a very modern, minimalist user interface. What you may not realize about lightning components is that each instance of the component inside of the template can be configured differently. I can drag-and-drop the same component five times, enter different parameters for each component and have it render differently on the page.

I am marrying a man who happens to dislike the Salesforce1 mobile app. Over the past few days, it has been a big subject of debate as he tried to figure out ways to work around using it on his iPad mini, such as using Opera as his mobile browser which does not support Salesforce1. Being the die hard Salesforce champion that I am, I got tired of hearing him complain and finally grabbed his phone to see what his issue was. After a few minutes of exploring, it quickly became clear where his pains came from:

1. Salesforce1 was turned on, but no customization was done, so he was seeing a ton of quick actions that were not relevant to his daily routine or sales workflow.
2. No training was done to explain to him how to get the most out of the app, so he was missing out on some key features and benefits.
3. He was not taking advantage of “Today”, which makes logging activities in Salesforce from calendar appointments stored on your iPhone really easy. Upon learning what it could do, he perked up because no sales person loves data entry and anything that can be done to reduce the number of clicks they needed to track activities is a huge bonus.

By the end of our conversation, he had set up the Today app and was taking notes on the things he wanted to ask his Salesforce Admin to look at so that he and his teammates could get more out of the mobile app. The good news is that his asks take minutes, not hours, to setup. They represent low hanging fruit than can quickly increase sales adoption.

Why Mobile Matters for Sales Leaders

When you have sales teams who travel frequently (e.g. my fiance who is in field sales and travels an average of three days a week), it is crucial that they can be productive on-the-go.

In fact, according to Salesforce’s recent “2015 State of Sales” annual report:

Nearly 60% of high-performing sales teams already use or are planning to use a mobile sales app (2x more likely than underperformers). Among all sales leaders surveyed, mobile sales app use will more than double in the next two years (125% growth).

You may have turned on Salesforce1, but if you have not optimized it for your team or trained them on how to use it, chances are, adoption and productivity could be far better. The good news is that you can easily fix this!

Take a Mobile-First Approach When Creating Page Layouts 

In the user experience world, there is a philosophy called “mobile-first” which essentially means that when you are rolling out a website, you should optimize it for mobile-first then scale up to a full browser view. This forces you to put the most important fields at the top of the page so users don’t need to scroll or navigate much, if at all, to get to the fields they need. It also helps to identify non-critical fields that may not actually be needed. To take a mobile-first approach when creating new page layouts, structure them so that the fields that users will be filled out most often on-the-go are are the very top section of the page. I would also recommend that any required fields be towards the top of the record to minimize the scrolling a user needs to do, or that a quick action be created to update fields lower on the page.

How to Make Salesforce1 Work for Your Team, Quickly 

If you turned on Salesforce1, but didn’t do much to customize it, the first thing you’ll want to do is modify the standard Salesforce1 and Lightning Experience Actions. Each page layout can have a different set of actions that your teams will use to effectively manage records in Salesforce1 or the new Lightning Experience. By default, there are a set of pre-defined actions assigned to each page layout. These can and should be overridden to improve your users’s experience. Sit down with your users and reorder the native actions, remove those you don’t want on there and identify any that are missing. Here are all of the quick actions that come out-of-the-box on an Account.  Once you make these changes, do a quick training for your users so they can learn how to get the most out of Salesforce1.

Also, be sure to customize your compact page layouts to control which fields show up at the top of the page below the account name and above the details. Try to keep the number of fields shown here to around 3 due to limited real estate. 

There are a lot of other ways to take Salesforce1 to the next level. These are just a few of the basics that every sales organization should be looking to do. Stay tuned for a follow-up blog post in the near future on using Quick Actions for Salesforce1.

Since the Salesforce Winter ’16 release notes came out in late August, we have seen customers eager to use the now extensible Napili template in the Salesforce Community Builder. Why? It offers companies a way to quickly setup an attractive, engagement-centric self-service community that is built on the modern Lightning framework and it is fully mobile-responsive out-of-the-box. From an architecture perspective, what makes it truly different from a Force.com community is the importance of topics in the community. They are at the core of how everything is tied together and crucial to understand. Here are 10 things that you need to know about topics in the Napili template:

1. Topics are the core of Napili and are used to categorize conversations and Knowledge Articles. Using topics is a logical choice in many ways; not only can Chatter posts be tagged with topics, but since most Salesforce objects can have topics assigned (using the Topics for Objects feature), it’s an easy way to tie data from different objects together and have a many:many relationship.
2. Topics are managed from inside the Community Management console. You can create topics, edit topics, merge topics, and delete topics. You can also create navigational topics and featured topics, which are also topics behind the scenes, just with super powers.
3. Navigational topics show up in the menu bar and control to which topics you can ask a question from the home page. If you’re on any topic detail page and click the “Ask a question” button, that topic will be populated in post destination field by default, but you can select to post it to any navigational topic as well. Navigational topics also have the ability to have their own header image.
   

   Navigational topics can be selected as a post destination

4. You can automatically escalate unanswered questions after a certain time period to different support queues based upon the topic to which the question was posted. This requires a combination of the process builder and Visual Workflow, and can be a bit tricky for those new to Visual Workflow. There are some tricks to the trade, like how to identify the primary topic to which the question was posted when a question has multiple topics assigned, but it can be done. If you let users create their own topics, you will want a catch all bucket to create a case for questions tagged with topics that you have not defined in your flow.
5. Featured topics are shown in square tiles on the home page and represent topics that you want to feature, hence their name. I personally like featured topics to be a subset of navigational topics, so that when you click on a featured topic image, it can have a matching header and a unified user experience. You can have featured topics that are not navigational topics, but users cannot post questions directly to them in this case and can only add the topic to the post as a secondary topic.
   

   Featured Topics

6. From a navigational topic, you can assign data categories. This is not actually storing the relationship between a topic and data category behind the scenes; instead, what is happening is that it is assigning that topic to all existing articles assigned to that data category. If you create new articles, they will not be automatically assigned any topics.
7. Articles must be assigned topics in order to show up in search results. This means that after publishing a new article, you need to assign it one or more topics, and this must be done from inside the community. Topics are community specific, so any topics assigned from your internal view of Salesforce will not show up in the community.
8. The discussions and articles that render on a topic detail page are those which have been tagged with that topic. Discussions show up in the order you define, and articles are sorted based upon some secret algorithm. Our theory is that it is based upon an article’s popularity.
9. You can enable users to create topics or use those that you have defined. If you enable users to create topics, the templates will actually make suggestions to community users about which topics to add. The obvious benefit to this is that if your community wants to talk about a topic that you have not thought of, they have the ability to do so and you will learn from them what topics most interest them. The downside is that you can end up with a proliferation of similar topics that your community moderators will need to clean up from time to time so that users clicking on #widget, aren’t missing all the conversations happening related to #widgets. Note: Topic permission are controlled at the profile level, so if your internal users have the ability to create topics in your internal Salesforce instance, they’ll be able to in your community as well.
10. The Trending Topics lightning component shows topics with the most conversations in recent time. When you setup a new community, you will notice trending topics will be empty until you populate test data. If there are no posts for a few days, you’ll see it show no results. This makes sense, as nothing is currently trending.

If you have any questions on topics in the Napili template that I didn’t cover in this blog, feel free to post your questions and I’d be happy to answer them!