This course is one of several, designed to prepare you on your journey towards completing the Salesforce Certified Sharing and Visibility Designer Exam. In this course, you will learn how to successfully setup a Territory model using Salesforce’s Enterprise Territory Management.

By the end of the course, you will know how to do the following:

1. Define Salesforce Enterprise Territory Management
2. Understand the benefits of using Enterprise Territory Management
3. Understand how to setup Territory Management in Salesforce
4. Explain the capabilities of Enterprise Territory Management and its impact on data visibility
5. Explain how Enterprise Territory Management impacts forecasting in Salesforce

The fictional company at the center of the story line for this course and the whole series will be Globomantics. The main character of the story will be a Salesforce Architect that has been asked to design the security model for this Salesforce Enterprise customer. The story for this course will be that the Architect is continuing her analysis of their org and is now assisting on building territories to help with account management.

If you are able to check out the course, I would love to hear your feedback. Especially, if you are using this course to help prepare you for the certification exam.

This will be the second of a series of posts I am doing on a new Pluralsight course titled, “Developing and Extending a Salesforce Community Experience with Code”.

Community Cloud (now known as Experience Cloud) allows you to easily create Lightning-based sites. Even though Salesforce offers many out-of-the-box components for these sites, many customers still want to customize sites with their own custom lightning components. This post will walk you through what might happen when a customer wants to customize their partner community.

Adding Components to Lightning Community

There are a few questions you need to ask yourself before creating a lightning component for your lightning-based Community.

1. Is there not already a standard component available or a free one on the App Exchange? If so, then it is best to use one of those before creating your own.
2. If you answered no to that first question, then the next thing to ask is, “Will this be an Aura or LWC component?” This is important to ask because each is developed not only with different tooling, but they involve very different developer skill sets.
3. But you may not be able to fully answer that second question until you have asked yourself the last question, which is, “What type of component do you need to build?” For now (at least), Aura-based components must be used to build any layout or theme components.

Building and Configuring Lightning Web Components

Lightning Web Components were introduced in 2019 and they represent the future of Salesforce development. They were specifically developed to address limitations with the original Lightning components, which are now known as Aura components.

Below you will find the code for a multi-component solution which allows users to search for and displays products as picture tiles. The container or parent component is called displayProducts.

Below is the HTML markup for the displayProducts component:

<template>
    <div class="slds-card slds-var-p-around_x-small">
        <template if:true={searchBarIsVisible}>
            <lightning-input
                label="Search Key"
                type="text"
                onchange={handleSearchKeyChange}
                class="search-bar"
            ></lightning-input>
        </template>
        <template if:true={products.data}>
            <template if:true={products.data.records.length}>
                <div class="content">
                    <template for:each={products.data.records}
                        for:item="product">
                            <c-product-tile
                                key={product.Id}
                                product={product}
                                draggable={tilesAreDraggable}
                                onselected={handleProductSelected}
                                class="slds-var-m-around_x-small">
                            </c-product-tile>
                    </template>
                </div>
                <c-paginator
                    page-number={pageNumber}
                    page-size={products.data.pageSize}
                    total-item-count={products.data.totalItemCount}
                    onprevious={handlePreviousPage}
                    onnext={handleNextPage}
                ></c-paginator>
            </template>
            <template if:false={products.data.records.length}>
                <p>There are no products matching your current selection</p>
            </template>
        </template>
        <template if:true={products.error}>
            <p>An error was encountered trying to get product data</p>
        </template>
    </div>
</template>

And here is the code for the client-side JavaScript controller:

// This component is very similar to the productTilelist LWC in the E-Bikes Sample app
// https://github.com/trailheadapps/ebikes-lwc

import { LightningElement, api, wire } from 'lwc';

// getProducts() method in ProductController Apex class
import getProducts from '@salesforce/apex/ProductController.getProducts';

export default class DisplayProducts extends LightningElement {
    // Corresponds to the targetConfig properties in the meta file
    @api searchBarIsVisible = false;
    @api tilesAreDraggable = false;

    pageNumber = 1;       // Current page in the product list
    totalItemCount = 0;   // The total number of items matching the selection.
    pageSize;             // The number of items on a page.
    filters = {};         // JSON.stringified version of filters to pass to apex  
   
    // Load the list of available products.
    @wire(getProducts, { filters: '$filters', pageNumber: '$pageNumber' })
    products;

    handleProductSelected(productId) {
        this.recordId = productId;
    }

    handleSearchKeyChange(event) {
        this.filters = { searchKey: event.target.value.toLowerCase() };
        this.pageNumber = 1;
    }

    handlePreviousPage() {
        this.pageNumber = this.pageNumber - 1;
    }

    handleNextPage() {
        this.pageNumber = this.pageNumber + 1;
    }

}

Nested inside the displayProducts component are two other components – productTile and paginator. The paginator component is one you can find the code for in this GitHub repo. The productTile component will direct the user to the product detail page and the HTML for the component is below:

<template>
    <div draggable={draggable} ondragstart={handleDragStart}>
        <a onclick={handleClick}>
            <div class="content">
                <img
                    src={pictureUrl}
                    class="product slds-align_absolute-center"
                    alt="Product picture"
                />
                <div>
                    <p class="title slds-align_absolute-center">{name}</p>
                    <p class="slds-align_absolute-center">
                        MSRP:&nbsp;
                        <lightning-formatted-number
                            format-style="currency"
                            currency-code="USD"
                            value={msrp}
                            class="price"
                            maximum-fraction-digits="0"
                        ></lightning-formatted-number>
                    </p>
                </div>
            </div>
        </a>
    </div>
</template>

And the JavaScript associated with that component is below:

import { LightningElement, api } from 'lwc';

import { NavigationMixin } from 'lightning/navigation';
import PRODUCT_OBJECT from '@salesforce/schema/Product2';

/**
 * A presentation component to display a Product__c sObject. The provided
 * Product__c data must contain all fields used by this component.
 */
export default class ProductTile extends NavigationMixin(LightningElement) {
    /** Whether the tile is draggable. */
    @api draggable;

    _product;
    
    @api
    get product() {
        return this._product;
    }
    set product(value) {
        this._product = value;
        this.pictureUrl = value.Picture_URL__c;
        this.name = value.Name;
        this.msrp = value.MSRP__c;
    }

    /** Product__c field values to display. */
    pictureUrl;
    name;
    msrp;

    handleClick() {
        this[NavigationMixin.Navigate]({
            type: 'standard__recordPage',
            attributes: {
                recordId: this._product.Id,
                objectApiName: PRODUCT_OBJECT.objectApiName,
                actionName: 'view'
            }
        });

    }

    handleDragStart(event) {
        event.dataTransfer.setData('product', JSON.stringify(this.product));
    }
}

Building and Configuring Aura Components

For Experience cloud communities, Aura-based components will typically only come into play when there is a need to customize the communities theme and layout. The type of customizations you may want to make include:

• Detailed layout structure
• Design tokens bundle
• Custom configuration properties used to customize the layout

For example, if I wanted to create a custom theme layout, I could create an Aura component bundle named customThemeLayout. This is what the markup for such a component might look like. Take special notice of the implements attribute as that part is key to exposing this to Experience Builder.

<aura:component implements="forceCommunity:themeLayout"
               access="global">
    <!-- Represent all the columns in the layout -->
    <aura:attribute name="left" type="Aura.Component[]"  />
    <aura:attribute name="right" type="Aura.Component[]"  />
    <aura:attribute name="navBar" type="Aura.Component[]"
                                  required="false"/>

    <!-- Configuration Properties in Design File   -->
    <aura:attribute name="leftColWidth" type="Integer" 
            default="7" />
    <aura:attribute name="rightColWidth" type="Integer" 
            default="5" />

    <div class="navigation">
        {!v.navBar}
    </div>
	<div class="mainContentArea">
        <lightning:layout>
            <lightning:layoutItem size="{!v.leftColWidth}">
                {!v.left}
            </lightning:layoutItem>
            <lightning:layoutItem size="{!v.rightColWidth}">
                {!v.right}
            </lightning:layoutItem>
    	</lightning:layout>
    </div>
</aura:component>

The layout theme above is designed for two columns and the sizes of those columns are configureable. Since I am using configureable attributes for the column sizes, I will need to include a design file in this bundle, such as this:

<design:component label="Two Column Configurable layout"> 
    <design:attribute name="leftColWidth" 
              label="Left Column Width" />
    <design:attribute name="rightColWidth" 
              label="Right Column Width" />
</design:component>

This will be the second of a series of posts I am doing on a new Pluralsight course titled, “Developing and Extending a Salesforce Community Experience with Code”.

Salesforce.com was launched in 2000 and one of the key marketing strategies was a “No Software” protest. It took six years to offer developers a way to customize the platform. Even then, the only method of customization was to use single JavaScript files called S-Controls. The introduction of Visualforce and Apex in 2008 was only a slightly better way to access the platform programmatically.

The multi-tenant architecture that made the Salesforce CRM so attractive to business people, did nothing to entice software developers. They saw Salesforce as a “walled garden” that was just full of annoying limits, along with out of date testing and deployment methods.

This perception continued even after Salesforce introduced the Lightning platform in 2015. Chained to a bloated JavaScript framework called Aura, Lightning components were spectacularly slow to render. Worse than that, they were supported by antiquated development tools.

Salesforce executives knew they had a problem. To address it, they made key decisions to reverse direction and also attract “serious” software developers. In this post, I will look at a few of those decisions, and some of the open source projects Salesforce is working on today.

Changing Directions – Salesforce DX

Salesforce has always embraced a strong culture that it referred to as the “Ohana”. Unfortunately, software developers were more like second class citizens in this culture. That began to change significantly in 2016 with the introduction of Salesforce DX (Developer Experience). 

Better Tooling

Salesforce DX is a set of tools, centered around source-driven development. It’s introduction was spearheaded by former Microsoft and now former Salesforce employee, Wade Wegner and is part of a campaign to win the loyalty of developers. The momentum continued after Salesforce released the Salesforce Extensions for Visual Studio (VS) Code as open source on GitHub. 

Unlike the rest of Salesforce, the VS Code extensions are updated every week. Salesforce actively adopts pull requests from community members, which includes feature requests and bug fixes. 

The Salesforce DX features have also continued to grow. One of the most significant was the ability to develop on a local development server. Finally, developers can disconnect from Salesforce servers to develop Salesforce DX projects faster. This has improved even more so recently with the release of Change Source Tracking.

Lightning Web Components

To address performance problems associated with Lightning components, Salesforce hired another former Microsoft employee, Kevin Hill to lead the effort of creating a new programming model. This resulted in the introduction of Lightning Web Components. It also involved renaming the original Lightning components as Aura components. 

Aura components would be fully interoperable with Lightning Web Components, but the newer programming model was clearly the future of Salesforce development. Lightning Web Components rendered much faster than legacy Aura components. This was due to the fact that they relied on web standards, such as web components that were now available in most major browsers. 

In an effort to secure the future of Lightning Web Components, Salesforce developers have become contributing members of the Ecma International Technical Committee 39 (TC39). This committee is directly responsible for controlling how JavaScript works in all browsers. Salesforce is also a member of the World Web Consortium (W3C), which controls the working group responsible for the web components standards. 

Utilizing web standards has not only resulted in huge performance gains, but it has also excited developers of popular frameworks, such as React, Angular and Vue. These developers quickly discovered that developing Lightning Web Components was instantly familiar to them.

Embracing Open Source

Salesforce did not stop there in trying to draw in more of these serious front-end developers. They have continued to offer up more of their software as open source. Even source code for jewels such as lightning base components are available on GitHub.

To help developers get up to speed quickly, Salesforce developer evangelists have created a Sample Gallery. The gallery features several real-world type applications that are updated on GitHub with every new Salesforce release. Each application showcases how to utilize Lightning Web Components, along with the latest available Salesforce features and best practices.

The latest addition to the sample gallery is the ECars sample car sales and service application. The customer facing application demonstrates the portability of Lightning Web Components and can be deployed on Heroku as a microservices application. It also features a Postgres database and uses Apache Kafka to handle incoming car diagnostic requests.

On the Horizon

Continuing with the Developer tools momentum, Salesforce has a few initiatives in beta and closed pilot.

Salesforce functions (in beta) will eliminate many of the pain points that currently exist when trying to integrate Salesforce apps with different languages and libraries. Developers will no longer have to create a separate app on platforms like Heroku. They will also not have to configure a Salesforce connected app and develop lots of code to communicate with REST API’s. Nope, all of that can use Salesforce functions to embed scalable communications directly inside of current apps.

Code Builder (still in closed Pilot) brings Salesforce Extensions for Visual Studio Code to the web browser. Everything you need to build powerful Salesforce apps is built right in. This not only includes a connection to your Salesforce org, but Git integration and productivity tools like ESlint. Unlike the wildly unpopular Developer Console, this online development tool will be a true modern developer experience.

Potential Roadblocks

Salesforce’s biggest roadblock to innovation is the same thing that brought it success decades ago. The legacy multitenant architecture that is tied to application and database core services can best be described as limiting. Salesforce is actively working to replace many of the platform services with microservices, but this is a work in progress.

Salesforce has certainly made a lot of progress in bringing down the walled garden. However, they are playing catch-up to big Industry players like Microsoft, Google and Amazon. Only time will tell over the long run how their new offerings fare.