Category: Salesforce

Implement and Use Lightning Service Components

As the Lightning ecosystem evolves, I have noticed and adopted a valuable architecture pattern: Lightning service components. In this post, I will present this concept, illustrate how it is increasingly used in base components and provide tips and best practices on how developers can create their own service components.

Understanding Lightning service components

Before diving into the specifics of Lightning service components, let’s define what a service component is: A service component is a component that provides an API for a set of functionalities. Ideally, the service should be specialized, generic and reusable.

Another important thing that differentiates a service component from other components is the fact that it does not have a graphical representation. Unlike other components, it is not visible by default. However, it can display some graphics (like a modal dialog or a toast notification) upon request if it’s a UI service.

We will use the term “caller” throughout this post to designate a component calling a service.

An overview of base service components

Since the introduction of the Lightning Data Service (the first base service component) in Winter ’17, the number of base service components has steadily increased over releases. As of Summer ’18 there are 13 base service components and this number is likely to grow in the upcoming releases.

Summer ’18 base service components

Here is an overview of the Summer ’18 base service components. Notice that the terms “library,” “API” and “service” are used interchangeably but these are all service components.

Name Component Category Description Lightning Data Service force:recordData Data Provides the ability to create, read, update, and delete Salesforce records in Lightning without the use of an Apex controller. Notification Library lightning:notificationsLibrary UI Displays messages via notices and toasts. Overlay Library lightning:overlayLibrary UI Displays messages via modals and popovers. Workspace API lightning:workspaceAPI UI API for accessing/manipulating workspaces (Tabs and Subtabs). Utility Bar API lightning:utilityBarAPI UI API for the Utility Bar. Navigation Service lightning:navigation UI Allows to navigate to a given page or to generate a page URL. Navigation Item API lightning:navigationItemAPI UI Allows to control navigation items in Lightning console apps, where navigation items display in an item menu. Quick Action API lightning:quickActionAPI UI Allows to control actions in Lightning Experience on record pages. Conversation ToolkitAPI lightning:conversationToolkitAPI Service Cloud Console integration API for Live Agent. Omni-Channel Toolkit API lightning:omniToolkitAPI Service Cloud Provides access to the API for the Omni-channel toolkit. Minimized API lightningsnapin:minimizedAPI Service Cloud Enables customization of the user interface for the minimized snap-in in Snap-ins for web. Pre-chat API lightningsnapin:prechatAPI Service Cloud Enables customization of the user interface for the pre-chat page in Snap-ins Chat. Settings API lightningsnapin:settingsAPI Service Cloud Enables to fetch certain settings from within custom components for Snap-ins for web. Using a base service component

All of the base components are documented with examples. For the sake of brevity we won’t examine all of them in detail in this post but let’s have a look at an example: displaying a notification with the notifications library.

The first

Salesforce Developer Wiki Retirement

Years ago, the Salesforce Developer Wiki was a trove of valuable technical resources but these days, there is a good part of those 1.6k pages that is now obsolete and duplicated by our documentation. We concluded that it was time to act for the sake of the quality and relevance of our technical resources.

After more than a decade of loyal services, it is now time to retire the Salesforce Developer Wiki.

Over the last few months, we’ve been scaling down the importance of the wiki by gradually unlinking it from our other sites. However, search engines keep on redirecting users to wiki content so we now need to make the final push and fully decommission it.


The Salesforce Developer Wiki was created more than ten years ago. It used to be the source of our developer documentation but it was also used for other purposes such as tutorials, blog posts and surveys.

What was great about it was the fact that it was written collaboratively by the community. This gave us good content with diverse point of views from a great variety of sources. Unfortunately, this collaborative nature also led to its downfall as it takes several full-time jobs, a few processes, and a robust strategy to structure and maintain such vast content. For example: each new release required a plan and resources to systematically review existing content and develop new content for newly released features.

As our company grew, we put in place strong content delivery and maintenance processes with dedicated documentation teams. We shifted our focus towards internally maintained documentation sites while reducing our efforts around the wiki. We felt that third-party sites and our blog would continue to provide diverse insights but that we needed to streamline coverage of our features.

Our plan

The Developer Wiki still holds unique and valuable content so we are taking care of preserving this precious knowledge. After carefully reviewing its content, we ended up redirecting and transferring most of it between:

We investigated and retired more than a hundred Developer Wiki links from 41 Trailhead modules and projects. This initiative guarantees the quality of your learning experience after we fully decommission the Developer Wiki (Meaning #No404Error).

Share your feedback

We would love to hear from you. Feel free to share your Developer Wiki experience and thoughts by commenting on this post.

What is Change Data Capture?

With so many different flavors of streaming events, how do you choose the right one for your use case? In this post, we’ll talk about our newest streaming event called Change Data Capture and compare it to the other events offered on the Lightning Platform.

Important: Change Data Capture is available as a developer preview in Developer Edition orgs. Change Data Capture isn’t generally available unless or until Salesforce announces its general availability in documentation or in press releases or public statements. All commands, parameters, and other features are subject to change or deprecation at any time, with or without notice. Don’t implement functionality developed with these commands or tools. In addition to the developer preview, Change Data Capture continues to be offered through a pilot program to select customers. To be nominated to participate in the pilot program, contact Salesforce. You can provide feedback and suggestions for Change Data Capture in this Trailblazer community group.

What is a Change Data Capture (CDC) event?

A CDC event, or change event, is a notification that Salesforce sends when a change to a Salesforce record occurs as part of a create, update, delete, or undelete operation. The notification includes all new and changed fields, and header fields that contain information about the change. For example, header fields indicate the type of change that triggered the event and the origin of the change. Change events support all custom objects and a subset of standard objects.

Event payload example

This change event message is sent when an account record is created with a Name and Description field.

{ “data”: { “schema”: “IeRuaY6cbI_HsV8Rv1Mc5g”, “payload”: { “ChangeEventHeader”: { “entityName”: “Account”, “recordIds”: [ “<record_ID>” ], “changeType”: “CREATE”, “changeOrigin”: “com.salesforce.core”, “transactionKey”: “001b7375-0086-250e-e6ca-b99bc3a8b69f”, “sequenceNumber”: 1, “isTransactionEnd”: true, “commitTimestamp”: 1501010206653, “commitNumber”: 92847272780, “commitUser”: “<User_ID>” }, “Name”: “Acme”, “Description”: “Worldwide leader in gadgets of the future.”, “OwnerId”: “<Owner_ID>”, “CreatedDate”: “2018-03-11T19:16:44Z”, “CreatedById”: “<User_ID>”, “LastModifiedDate”: “2018-03-11T19:16:44Z”, “LastModifiedById”: “<User_ID>” }, “event”: { “replayId”: 6 } }, “channel”: “/data/ChangeEvents” }


When to use Change Data Capture

Use change events to:

Receive notifications of Salesforce record changes, including create, update, delete, and undelete operations. Capture field changes for all records. Get broad access to all data regardless of sharing rules. Get information about the change in the event header, such as the origin of the change, which allows ignoring changes that your client generates. Perform data updates using transaction boundaries. Use a versioned event schema. Subscribe to mass changes in a scalable way. Get access to retained events for up to three days. Example: Data replication to an external data store

Get Cloudy Consulting has a project for a client. This client wants an integration that synchronizes Salesforce record data changes with their HR system, which is external to Salesforce. Some of the client’s HR data is created and modified in Salesforce as Employee__c custom object records. The client wants the employee data in the external HR system to be in sync with Salesforce.

The integration app has the following requirements:

Every new

The Developer’s Guide to Dreamforce 2018

We’re a bit over a month away from Dreamforce ’18 and we’ve got a lot in store! Whether you’re joining us in-person or online, this guide will help you as a developer to make the most out of your #DF18 experience.


Watch the Developer Keynote
Lead Developer Evangelist Zayne Turner, Architect Christophe Coenraets, and Principal Mobile Architect Qingqing Liu will deliver a sneak peek of the latest in Salesforce development. Don’t miss out — bookmark the keynote when the Agenda Builder goes live. (And if you’re not joining us in-person for the keynote, #NOFOMO — we’ll be livestreaming on Salesforce Live!)

Attend hundreds of Developer Sessions
We’ve got around 200 developer sessions in our theaters and breakout rooms — bookmark these sessions now (select the filter Role = Developer) and plan your session journey so you don’t miss out on great sessions for you. We’re already getting lots of buzz on sessions about Lightning Components, Salesforce DX, and Einstein!

Explore the Developer Forest
Product experts will be staffing a ton of demos in the Developer Forest. Drop by and ask questions about updates to the products you use every day, and discover new ones that will help you build better apps, faster. You can also give experts direct feedback about product roadmaps! Plus, new for 2018 you can stroll through the Tree of Integration, where we’ll demo how to connect your Salesforce apps in new ways; for example with MuleSoft.

Take a stroll through Einstein Park
Learn how to make apps smarter in Einstein Park, where product experts can walk you through everything Einstein, including Einstein Analytics. Whether you’re new to Einstein or looking for power tips, Einstein Park is where it’s at for everything AI.

Visit Robotics Ridge
Robotics Ridge was a big hit at TrailheaDX, and it’s back and better than ever for Dreamforce! This is a fun opportunity to see first-hand how different Salesforce technologies — including Lightning Platform, IoT, Platform Events, and Heroku — can work together and power a manufacturing line…of robots!

Skill up at Trailhead Bootcamps
We’ll be hosting developer-focused Bootcamps September 22-24, 2018, before the conference kicks off. Learn more and sign up in our blog post.


Meet fellow developers at the Trailblazer Community Cove
Dreamforce is all about the Salesforce Ohana, and the Trailblazer Community Cove is the perfect place to find your developer Ohana. Learn more about the online and offline Trailblazer Community, and trade stories with others.

Have fun

Win cool swag
Unlock prizes by completing special activities in different areas of the Trailhead Zone.

Take pictures
There’s photo opportunities so you can capture your #DF18 memories for years to come. Astro and friends may also be around to meet, greet, and photobomb your shots!

Rock out at Dreamfest
Dreamfest is one of the biggest, can’t-miss events within Dreamforce. Check the Dreamforce website for more details about this year’s Dreamfest (coming soon!).

Give back

Learn, earn, and give back by playing the Dreamforce Quest
Learn new developer skills, earn a limited edition community badge, and win a prize

All About Custom Lightning Page Templates

Have you ever wished for a new layout for your home page? How about more control over the columns on your record page? With the custom Lightning page template feature and a little bit of code, you can go way beyond the out of the box templates. This blog post is going to help you get started with your own templates and then we will dive into some cool things you can do!

What is a Lightning page template anyway?

Lightning page templates are components that define a page’s regions and can be used for Home, Record or App pages. Both standard and custom templates appear in the App Builder’s New Page Wizard and can be used to create new pages for an app. They are pretty easy to create, so let’s dive in!

Getting started

There are a few things you need to be aware of when building a new Lightning page template. The most important thing is to decide where you want your template to be used. You must specify if you want it available on an App, Home or Record page. You have to pick only one, since you can’t use more than one interface.

The next thing to be aware of the .svg file, which is an image type. This file works differently for Lightning page templates than Lightning components. For a component, an .svg would show up in the left-hand bar of the Lightning App Builder. For a Lightning page template, it shows up on the screen where you select which template you want to use. No matter what you do, your custom templates will appear in the new page wizard, but if you leave the .svg alone, it will be hard to distinguish your templates from each other. You can add an .svg file to provide App Builder users with an image preview of the template.

The black box here identifies where the .svg will appear.

Exactly what your users asked for: A Home Page with three regions

We’ve just received a request for an amazing custom Lightning page template in our org. Our first step is to dream about what kind of page we would like. Let’s imagine that your users have requested a Home page with three columns. It’s a pretty standard ask with a simple look and feel, but you draw it up anyway, just to be sure.

Next, we are going to create a brand new Lightning component. So we can remember, we’ve called it ThreeRegionHome (so creative, right?). We’ve got to make sure we implement the right interface for a Home page and we add a description, because we are great developers. Since we know we only need three regions and they are going to be columns, we create some attributes for those. So far our component looks like this:


<aura:component implements=”lightning:homeTemplate” description=”A home page you always dreamed of, 3 collumns.” > <aura:attribute name=”column1″ type=”Aura.Component[]” /> <aura:attribute name=”column2″ type=”Aura.Component[]” /> <aura:attribute name=”column3″ type=”Aura.Component[]” /> </aura:component>


New Density Settings for the Lightning Experience UI in Winter ‘19

We’re continuing to enhance the Lightning Experience UI in response to customer feedback. In Winter ‘19, we’ll give individual users the power to control their UI “Density Setting” in Lightning. In addition to the current view we’ve had through Summer ‘18, which we now call “Comfy”, we’re releasing a higher-density view option called “Compact.” The difference between the two views can be summarized as:

Comfy: a spacious view with labels on the top of fields and more space between page elements. Compact: a denser view with labels to the left of fields and less space between page elements.

We’ve also darkened some of our text colors to go above and beyond the color contrast requirements of the W3C’s WCAG 2.0 AA, the industry standard for web accessibility.

The above image compares the same record view across Salesforce Classic (left), Lightning Experience Comfy view (middle) and the new Lightning Experience Compact view (right) when looking at record details. As can be seen, the Compact view provides a 30% increase in information density compared to the Comfy view and reaches information density parity with Salesforce Classic.

As a developer of custom pages and components for Lightning, you may need to make some simple changes to your code to ensure the UI looks responsive to the user’s display density setting.

Below we cover the different ways you might’ve implemented your custom pages and components, plus recommendations on what steps to take.

First, and as context, we discuss the guiding principles from a User Experience perspective.

Guidelines from the User Experience team

This feature is all about giving users choices about how much information density suits their individual needs in the Lightning Experience user interface. Rather than compromising on “middle of the road” values that are not ideal for anyone, we are defining separate sets of optimized values for a “Comfy” view that has larger spacing and a “Compact” view that prioritizes the amount of information displayed on screen.

The Comfy view remains as close to previous Lightning releases as possible. The Compact view is designed to meet, or exceed, Salesforce Classic information density in key screens such as list views and record detail forms.

For the Winter ’19 release we concentrated on three main areas in the UI:

Spacing Applied to padding and margin values between elements Line height for text blocks Form element alignment on record details Top aligned in Comfy mode Left aligned in Compact mode (when the details are shown in the wide region). Note: if available form width falls below a predetermined threshold in the wide region (e.g. because of browser viewport resizing), labels will automatically shift to top alignment. Title font size Applied to higher level text elements (not body copy)

We power these changes through Salesforce Lightning Design System (SLDS) variable design tokens and classes. These give the most dramatic changes to the UI, while allowing developers to apply simple and defined CSS changes to ensure their components and features can take advantage


The Dreamforce Developer Track 2018: How We Select Sessions

The Salesforce Developer community showed up in full force for our Dreamforce 2018 Call for Presentations. On June 15, 2018, we asked you to submit your best ideas for presenting at Dreamforce 2018 in the Developer Track. Straight out of the gate, we couldn’t refresh our dashboard fast enough to keep up with the submissions that were pouring in!

By the time we closed the CFP on July 15, 2018, we had received over 970 Developer Track submissions, which is 26% more than we received last year. Between the Developer and Admin Tracks, we had about 1,900 submissions! With those numbers we could host another couple of Dreamforces right after the official one!

So many of you shared your ideas, and you’re probably wondering what we do with them. Why did your session get picked? Why didn’t it? Here’s more info on how the Developer Track came together.

Picking the panels: Assemble all advocates!

Prior to launching our Call for Presentations, we recruited a group of 40 Salesforce employees from different departments to be session owners and submission reviewers. They are Salesforce Admin and Developer advocates from across the company who know the role of the Salesforce Developer very well. These 40 people not only review submissions, but also work closely with presenters to bring these talks to life on stage at Dreamforce.

But that’s not all — we also extended a call to our Salesforce MVP Community to help us with feedback and about one hundred MVPs stepped up to help!

We can’t take all the submissions (but we wish we could)

Of course, we can only select as many sessions as Dreamforce can physically hold. For the Developer track, this turned out to be just over 200 sessions across 20-minute Theater and 40-minute Breakout formats. From that number we load balanced between the two things we know developers want:

Information about our platform directly from the engineering teams that build the products Best practices from our passionate community based on their implementation experience

To achieve this, we allocated roughly half of our inventory for the product teams and the other half to be chosen from the 970 submitted Call for Presentations.

The feedback process: Scalable session selection

With 1,900 submissions for the Admin/Dev Track, more than a dozen products and close to 200 stakeholders, team members, session owners, and MVPs to give feedback on those submissions, we needed to completely reinvent our feedback process.

I built an internal feedback app on Salesforce. This app asked key product stakeholders to rate each submission on how well-written the title and abstract are, how useful the information is, and how innovative the content is. The result gave each submission a karma score.

At the same time, Admin Evangelist Gillian Bruce used GetFeedback to craft a way for session owners and MVPs to rate every session at scale. For this part, only the title and abstract were shared, not the speaker name to make sure the submission was evaluated based on content