Salesforce Lightning – a Primer
Since the beginning of the 21st century, Salesforce has grown from relatively humble origins in the then nascent Software-as-a-Service (SaaS) industry to becoming the dominant CRM platform in 2016. Along the way Salesforce has broadened its reach to cover many different aspects of contemporary enterprise cloud computing: sales, service, marketing, analytics, community, social and mobile apps, amongst others.While the primary enterprise offerings from Salesforce continue to be the various Clouds (Sales, Service, Marketing, etc.), in the last decade or so a thriving developer community has built up around Salesforce’s Force.com Platform-as-a-Service (PaaS) suite of development tools. Force.com allows developers to build upon the out-of-the-box flavours of Salesforce.com, to extend functionality where necessary, and to build standalone apps running on Salesforce’s underlying multitenant architecture.
In this post I provide a potted history of development on the Force.com platform to set the context for the latest innovation, Lightning. While configuration (clicks not code) of the platform remains a huge part of the process, I will concentrate on how Force.com can be used to extend Salesforce programmatically. I will then turn to the latest addition to the Force.com family – Lightning – and explore how it represents a major shift for Force.com and the broader Salesforce suite.
This post is aimed mainly at Salesforce experts and developers; however it will be useful to a wider audience, such as web and app designers/developers, UX experts, and managers evaluating different PaaS development offerings.
A Short History of Force.com Development
All this changed in 2008 when Force.com was introduced, with Apex and Visualforce. Apex is a fully featured programming language, running server-side, which allows developers to directly access and control Salesforce’s data model and functions; it is based on Java, and so will be familiar to any Java developer. Visualforce is a component based user interface framework, including a tag based mark-up language similar to HTML. Together they can be combined using the traditional model-view-controller (MVC) design pattern, providing developers the ability to build custom pages and apps strongly integrated with Salesforce.
Apex and Visualforce have dominated Salesforce coding ever since; they provide a powerful yet easy-to-use means to extend the platform. In the last few years, however, there have been shifts in the wider world of web development. Increases in both software and hardware performance, and changes in the needs of users, have led to a move away from traditional page-centric, server-side scripting, towards a greater emphasis on client-side scripting. This is has been partly driven by the rise of mobile technology, which has also required improvements to the UI, specifically in the areas of responsive design and data input (fingers, not keys), and reductions in calls to the server due to limited network bandwidth.
A whole ecosystem of client-side scripting and user interface frameworks have sprung up (jQuery, AngularJS, Bootstrap, etc.) to accommodate these shifts in the way people use web technology. Of course, Salesforce developers were keen to get in on the action!
Salesforce were certainly not unaware of these changes in the mobile world. In 2013 they introduced the Salesforce1 mobile app. Although there had been previous incarnations of a mobile app for Salesforce (Salesforce Classic and Salesforce Touch), this was the first time most of the Salesforce functionalities were available on a mobile device. And it’s also where Lightning enters our story…
Salesforce realised that they needed to build a mobile-optimised UI for Salesforce1. To do this they developed a scalable, component-based user interface framework that allowed the reuse of discrete UI components across different pages. The framework bridged client-side and server-side scripting to provide fast responsiveness combined with more complex business logic, again driven in part by the need to limit calls to the server on mobile devices due to network bandwidth limits. The framework also had the responsive design elements necessary for mobile built in from the foundations. This became the Lightning framework, upon which the Salesforce1 app was built.
(In fact the Lightning framework is based on the Aura framework, which started as an internal initiative within Salesforce, and has subsequently been made open-source.)
A year after Salesforce1 was launched Salesforce opened up the Lightning framework to developers, allowing them to create their own components (Lightning Components), and to modify and extend Salesforce’s own components. This, along with the Lightning App Builder, could be used to quickly and easily create new apps for Salesforce1.
The next logical step was the unification of mobile and desktop across the Salesforce platform, using Lightning. At this point, Salesforce desktop users were still using the same user interface introduced in 2010, which by now was starting to look a little long in the tooth. Developers have always been somewhat frustrated by the restrictions placed on modifying standard page layouts in Salesforce, having to resort to Visualforce more often than not to fulfil their requirements. While technically possible to use Lightning Components within Visualforce, or to create standalone Lightning apps for the desktop, there was not an easy way to integrate Lightning Components directly into the old UI.
Finally, in 2015, Salesforce announced the Lightning Experience. This was the biggest change to the desktop user interface in years, bringing the new component based UI from Salesforce1 to all devices. Developers could now develop Lightning Components and Apps and integrate them directly into Salesforce.
The Salesforce Lightning Family
Now that the background has been covered, I want to expand a bit on each of the different parts of Salesforce Lightning – as a marketing phrase it is used extensively and sometimes confusingly! What follows is a breakdown of each Lightning element:
Lightning Component Framework
Salesforce1 and Lightning Experience are both built upon this framework.
Lightning Components can be configured to appear in Lightning Experience, via the App Launcher or as components in standard page layouts (although this is only available in beta at the moment), and Salesforce1, via the Navigation menu or in Lightning Pages. They can also be used in Lightning Community pages.
The difference between Lightning Applications and Components is that you can only access Applications from the browser URL – they are intended to be standalone apps, rather than components used within the Salesforce1 app or Lightning Experience. It is not possible to access a Lightning Component directly from the URL, however, it must be wrapped in an Application.
You can access a Lightning Application using the URL:
where <myDomain> is the name of your custom Salesforce domain.
Lightning Experience is itself a Lightning Application, with the URL:
A custom page layout, built in the App Builder for Salesforce1 by drag and dropping Lightning Components on to the page. It is not possible to see these pages in Lightning Experience at the moment.
Lightning App Builder
A point-and-click tool that can be used to create custom mobile app pages for Salesforce1. It is also possible to modify standard page layouts in Lightning Experience in the same manner, although this is in beta at the moment. The idea behind the App Builder is to allow non developers to create their own pages by dragging and dropping pre-configured components (standard or custom) onto the page. The Lightning Framework will handle responsive design across different sized devices – the user just needs to select from a list of different page layout templates.
It will be possible to add Lightning Components directly into standard page layouts, using the App Builder (this is in beta at the moment). Custom Lightning Components and Applications can be accessed via the App Launcher page.
Visualforce is still supported, and will continue to be; however there are some minor changes to how it works (the main one being that Visualforce pages now run in an iFrame within the Lightning Experience app, so page navigation needs to be modified).
Lightning Community Builder and Templates
Similar to the Lightning App Builder, this provides the means to build Salesforce Communities with Lightning Components. Based on a number of templates designed for different types of community, the developer can add and modify functionality easily, by dragging and dropping new components on to the page.
Lightning Design System
A CSS framework designed for use in both Visualforce and Lightning Components. It provides a means to produce custom pages, components and apps that match the look and feel of the standard Salesforce1 and Lightning Experience UIs. It provides a responsive grid layout system, and has accessibility baked in.
It is comparable to other frameworks, such as Bootstrap or Foundation, but is specifically tailored to comply with the Salesforce design principles.
Originally branded as External Data Objects, this functionality allows external data sources to be defined and interacted with in Salesforce as if they were standard Salesforce SObjects. It uses the OData protocol to connect to the external data sources.
Lightning Schema Builder
A rebrand of the existing Schema Builder, used to visually configure and manage the underlying Salesforce data model.
Lightning Process Builder
Another rebrand, this time of Visual Workflow, the graphical workflow tool that can be used to automate business processes. It replaces some aspects of traditional workflow rules and Apex triggers.
This is the section of Salesforce AppExchange dedicated to Lightning Components. Third party developers provide custom Lightning Components dedicated to specific industries or areas of functionality.
Implications of Lightning
It is inevitable that, with Lightning, Salesforce developers are going to have to learn to code differently than they do at the moment (client-side centric with reusable components, rather than page-centric on the server), and also to understand web design to a greater extent.
Lightning is a new technology and, in my experience, is still in its infancy in the development community. It is a little too early to say how it is likely to affect timescales for delivery, but there will likely be an impact during adoption so we will see a slowdown initially, while everyone gets used to the new approach. This is a good reason for people to start using Lightning as soon as possible!
Finally, with Lightning, there is a much greater emphasis on building reusable modules of functionality. Developers would benefit from creating a library of reusable Lightning Components that could be deployed across projects, as this would speed up subsequent development effort and allow a consistent approach to be followed.
Lightning is a powerful addition to the Force.com toolkit, however it is also a new technology and many Salesforce developers used to Visualforce and Apex may find they struggle at first to migrate over. This is the direction that Salesforce is going with Force.com development so it is important that developers become accustomed to it.
Thankfully there are many resources available online to help the process.
Salesforce provide certification in various areas and at various levels of proficiency.
Further help can be found within the Salesforce Developers community
Finally, I can’t recommend enough the excellent Salesforce Trailhead. This site provides free tutorials in all aspects of Salesforce, including Lightning. It uses gamification to help make learning more fun, and allows developers to attempt challenges (and be assessed on the results) within their own developer orgs.