The most recent release of CRM platform Salesforce included two different user interfaces—Salesforce Classic (essentially an update of the existing interface) and Lightning, which Salesforce.com bills as a completely new “user experience.” More than a GUI, Lightning represents a sweeping reinvention of the prior interface. Its functionality and the code that underlies it are substantially different from the standard (now Salesforce Classic) interface.
More importantly for organizations customizing Salesforce, or those writing custom apps for Lightning, it is a far more extensive feature set, including the ability for developers to undertake significant customizations that manage and/or enhance the user experience. This capability is appealing, but it also increases the risk of performance issues.
Salesforce intentionally designed Lightning to be intuitive and user friendly, with the look and feel of a consumer app rather than an enterprise console. These improvements, paired with its broad customization options and the fact that it is device agnostic, increases testing complexity for companies that adopt it.
Although Salesforce.com Customer Service asserts that performance profiling tools are sufficient to achieve good performance when customizing Lightning, in our experience that position is overly optimistic. Given Salesforce’s stringent requirements (and potential punitive actions) relating to the performance of client-side development, prudent customizing organizations will take responsibility for their own testing, including extensive performance testing.
This article will explore some of the performance—and performance testing—considerations for Lightning. In addition, Orasi recently wrote a white paper that details performance testing considerations and strategies for customizing the latest version of Salesforce as a whole, including Lightning. To request a copy, click here.
Customizing Lightning
As with Salesforce Classic, Salesforce provides users with the ability to customize their Lightning Experience in specific ways. Beyond that, however, it empowers developers to make sweeping customizations on the user’s or organization’s behalf. Given Lightning’s expansive feature set—and the reality that the most efficient deployment gives users in varied departments convenient access to different elements of Lightning—it makes sense for developers to undertake such an effort. It also increases the complexity of the codebase. Potential customizations for Lightning, all of which have performance implications, include but are not limited to:
- Lightning Actions: Bits of functionality that provide an accessible way for users to execute actions they customarily perform during the day.
- Customized page layouts, which can include:
• Actions (see above)
• Canvas Apps (Third-party apps integrated through the Force.com Canvas toolset)
• Custom Links
• Fields
• Related Lists
• Standard and Custom Buttons (As with Salesforce Classic, these are treated as Actions. Note that Custom buttons that call JavaScript are not supported in Lightning Experience.)
• Visualforce Pages - Lightning “Apps”: Unlike the standalone mobile apps developed to interface with Salesforce, Lighting Apps are custom web-app pages that create flexibility and extend functionality within Lighting. They aggregate multiple components on a single page to provide users convenient access to specific functionality, including links to third-party Salesforce apps. Options include:
• Single-page apps that drill down to standard pages
• Dashboard-style apps, such as apps to monitor and track top sales prospects for the quarter
• Apps to solve a particular task, such as an expense app for users to submit and monitor expenses
• Custom, user-tailored record pages for objects
• Custom Home pages containing the components and features users rely upon most
Testing For Lightning Adoption
Whether they choose Lightning as their sole user experience or as an option to Salesforce Classic for specific users or roles within the organization, enterprises moving to Lightning should not undertake the process lightly. Considerations for testing in general, and performance testing specifically, include:
- Salesforce reports most existing customizations should remain intact through Lightning adoption. However, depending on the extent of customizations and the complexity of the underlying codebase, this is often not the case. In conjunction with the Lightning upgrade, firms should:
• Confirm existing business processes and test cases are in working order.
• Ensure all existing Salesforce customizations—not only those that alter or affect Salesforce Classic or its integrations—have been fully tested and all deficiencies remediated.
• Plan to retest customizations at the conclusion of the effort, prior to going live. - Salesforce Classic can be tested headless, but Lightning cannot. It requires GUI testing with a tool such as HPE TruClient, which will in turn require a load-generating system. Organizations will need access to powerful load generators, either in-house or cloud-based, to handle the testing loads.
- Salesforce offers a mechanism for users to switch between Lightning and Salesforce Classic, but this does not minimize the need for testing the new user experience.
- The broad compatibility of Lightning will necessitate extensive browser and device performance testing, including the latest versions of Chrome, Firefox, Safari, and Edge. (This directive is especially applicable to organizations building custom apps.) Companies who move to Lightning must ensure their performance testing tools support the latest versions of these browsers.
In short, organizations planning a Salesforce upgrade will already be undergoing comprehensive testing and change management. Lightning complicates matters significantly. The new user experience, while compelling, should only be enabled after the core Salesforce upgrade—with the Salesforce Classic interface—has been fully and successfully tested, including performance testing. When enterprises are ready to add Lightning, they should be prepared for additional, extensive testing.
