Salesforce is always hard at work to make the user experience better with improved features that enhance efficiencies and make the product more secure. One of the most noticeable changes they released over the past few years was the Lightning framework, also known as LEX.
The Classic Interface.
What is Salesforce Lightning?
The Lighting framework was a follow up to the original Classic framework that Salesforce developed early on. In fact, most users today that have been around for 5-10 years started out on Classic, as Lightning was in the midst of ramping up to the framework it is today.
The Classic framework set the foundation for Lighting, as many of the features available in Lightning came from Classic. Dashboards, reports, and most (if not all) of the standard objects were available in Classic. Admins still had a wide range of capabilities with what they could create, and developers could use Classic effectively, as well, with Apex classes and triggers.
However, over time, Salesforce acknowledged some of the shortcomings of Classic, and baked in functionality to Lightning to handle some of those issues without as much hands-on work from admins and developers.
This article will go into some of the differences between Salesforce Lightning and Classic, and determine whether or not Lightning is better than Classic.
What are the pros of Salesforce Classic?
The Salesforce Classic framework has provided a very familiar user interface that many end-users and system administrators have become comfortable using. It provides a lot of basic functionality that many companies can use successfully and with confidence. The layout is very basic, but easy to maneuver, providing the ability to find almost everything you need in either a tab or within the Quick Find search bar.
Salesforce Lightning can sometimes nest things that are not so obvious to the system administrator, and can take some research to find. For example, you must know that the Lightning App Builder is where certain adjustments may need to occur for record pages, but you would more than likely try to make those changes in Page Layouts within the Classic framework.
Classic also provides flexibility in Visualforce and URL Hacking, the latter of which Lightning does not support. Visualforce is a framework that provides admins and developers to build unique user interfaces that work better for their needs when standard functionality cannot. While Visualforce can still be used for Lightning, there are so many pieces of Visualforce that are available natively with Lightning that there are concerns it may be phased out in the future.
URL Hacking is not necessarily a best practice for Salesforce users to follow, but it is something that many have used in Classic from time to time. URL Hacking is when an admin ‘hacks’ the URL of a new record to include information for populating fields automatically when the record is created. This is most common in something like a custom button, such as when a new opportunity record needed fields pre-populated to save the end-user time.
Let’s take a look at some of the differences between Lightning and Classic.
5 Differences between Lightning and Classic
For all of the overlap between Lightning and Classic, there are major differences with Lightning that make it stand out a bit. This, of course, is not a conclusive list, but does include some of the more exciting parts of Lightning.
- A Unified Experience with Salesforce Mobile App. One noticeable difference between Lightning and Classic is the more unified experience Lightning offers its end-users. With Classic, there was no easy transition between desktop and mobile. Not only did Salesforce retire the first iteration of the mobile experience (called Salesforce1), but they recently released a new Salesforce app in late 2019 that makes switching between desktop and mobile a lot easier.
The Salesforce Mobile App includes Lightning apps and navigation, and can enable sales, management, and whomever else is on the go to continue through their day without worrying about getting back to a desktop. It’s customizable, and works well with other features such as Einstein, reporting, and Salesforce Maps. This continual flow from one device to another means no more waiting for the convenience of a desk to enter your data!
- Easier Functionality for Admins and Developers. There are a lot of things in Lightning that are easier to use for system administrators, such as your Salesforce admins and developers. For example, many features within Lightning, such as the Lightning App Builder and Flow, that utilize drag and drop functionality. These canvas like displays help admins see the “bigger picture” and can see the layout changes in real time. There is less coding knowledge required for Lightning components, which means admins have a wider range of capabilities with similar impacts to a developer.
Likewise, reporting has become easier to use and has also incorporated time-saving features such as the ability to remove unwanted columns by closing out those fields in a list. Dashboards have also become more efficient by providing admins the ability to adjust sizes of components simply by dragging to the desired size, and move them around accordingly. These changes help admins and developers move through their tasks more efficiently.
Drag and Drop makes Lightning so easy to use!
- Dynamic Pages. Many users of Salesforce Classic have had the painful experience of dealing with multiple page layouts for specific record types and user profiles. For example, if there are a variety of sales teams, or industries, the opportunity page may need to look different for each one. In Salesforce Classic, admins are limited with their capabilities to provide a solution for this, and usually must create a separate page layout for each scenario. However, even if there are shared fields across those opportunities, they must still be addressed on each layout. This issue continues if a massive page layout change needs to occur and it can be a lot to map out or try to remember.
Dynamic Pages is a great feature that is available in Lightning App Builder, which allows visibility filters to be used for components, which dictates whether they appear on the page layout. This is very useful for grouping fields and setting their visibility to the user profile, to limit who can see them. That way, one page layout can be used, with component visibility reducing clutter and making the experience more efficient for both admins and end-users.
- Support for New Features. For those that have been using Salesforce for a few years, it is becoming increasingly clear that new features being released are done so with the Lightning framework in mind. Due to the modern, clean design, and easier user interface, Lightning seems to be more preferred for most features.
Each release seems to push more adjustments and improvements for Einstein, Support Console, and Sales Cloud, just to name a few. While there is Classic functionality for each of these, they are not necessarily designed for Classic. Salesforce Quip and Communities, for example, are not available in all Classic orgs, but are options for all Lightning orgs.
- Link to Related Records. In Salesforce Classic, if you start to create a child record, but don’t have the parent record created just yet, you’ve hit a major roadblock. You then must open a new tab, or navigate away from the record, but in both cases, will lose the progress already made on your new record. This can be very frustrating, and time consuming.
In Lightning, you can create child records without the parent record already existing. Using a lightbox functionality, if you are in the midst of creating a child record, you can also create a parent record, without losing the child record. This option appears when you select the lookup field, and you can select “New Record”. The page layout for that new record appears, and you can populate the data and save, thus returning to the child record. This is effective at both saving time, and increasing accuracy.
For all that Lightning offers that Classic does not, it still has a flaw or two. One of the biggest complaints of Lightning is that many users can frequently experience caching issues. This means that if changes are made too quickly, the user interface cannot always reflect such changes. This can lead to hours of frustration for users, as it is not always apparent that this is the issue, and can lead even the best admin to doubt the efficacy of their work. The best remedy for this is to do a hard refresh after changes are made on the backend, or close out records and reopen them to try the process again.
How do I Transition from Classic to Lightning Experience?
Salesforce has done a great job of launching a campaign in helping companies switch over from Classic to Lightning experience. If efforts are not made to properly plan out how the transition should occur, it can have negative impacts on both accessibility and functionality. Salesforce understands this and has taken steps to assist companies with such a task.
Lightning Experience Transition Guide!
They have created a Lightning Experience Readiness Check that can scan through your org and identify areas of weaknesses that can impact your transition to Lightning, and present a report for further evaluation and planning. Salesforce suggests rolling out Lightning Experience in your org through a series of phases.
- Discovery Phase: learn more about Lightning and why it is so beneficial to consider at this point in time for your company.
- Roll Out Phase: launch your change management strategy, take action, and release to your company.
- Optimize Phase: drive user adoption with documentation and training sessions for your end-users.
It is best to allow yourself weeks, if not months to complete this rollout to give yourself time to address issues as they arise. And, as always, allow ample time for testing from the perspective of both a system admin and an end-user.
Ultimately, it seems that Lightning Experience is the better quality framework from Salesforce. Classic is still around, but there’s no guarantee for future support regarding new features and releases.