JavaScript We know you love JavaScript buttons and have been using them in Salesforce Classic for many years. As a matter of fact, we’ve heard that many customers are reluctant to migrate to Lightning Experience because of the missing JavaScript button functionality. But Lightning Experience offers so much more than our Salesforce Classic, and it is the future. We realize that you expect and rely on us to always migrate existing functionality to new features and UI, but in the case of JavaScript buttons, we believe that the future is brighter in Lightning Experience, even without JavaScript button support.

JavaScript buttons and links are types of actions in the Salesforce Classic UI that allow you to create inline JavaScript code that can be invoked via a button or link embedded on a record or list page. For example, we have customers who pre-populate new records with data upon creation, update values in fields based on other logic, and partners who use custom buttons to integrate with their platforms.

If JavaScript buttons are so useful, why not support them in Lightning Experience? The issue is that combining untrusted JavaScript from multiple sources and authors together with the application source code, while maintaining trust of the overall application, has significant security challenges.

In this blog series, we’ll cover those security and functional challenges, and share with you the alternatives to JavaScript buttons that are mobile and Lightning-friendly. We’ll cover existing and upcoming features in Salesforce that you can use to migrate the functionality that you’ve built using custom buttons.

We’re committed to solving the problem of client-side customization and integration. We intend to show you a new approach to thinking about JavaScript button functionality in Lightning Experience that is better for everyone.

Overview of the Series

Part One: Why It’s Time to Break Up with JavaScript Buttons and Embrace Lightning
JavaScript is critical to web development, but On-Click JavaScript buttons have risks that made Salesforce look for alternatives that you can use for customizing the application. This article covers the reasons for the decision, highlights the common uses cases for JavaScript buttons, and offers insight into why the alternatives can be better.

Part Two: Take the First Steps: Ways You Can Replace JavaScript Buttons
Highlighting the most common use cases for JavaScript buttons, this article covers the available features in Salesforce that can be used to address that functionality in Salesforce1 and Lightning Experience. Utilizing Quick Actions and Apex, customers and partners have already started migrating to Lightning Experience.

Part Three: Your New Life With Lightning Actions: Smart, Fast, and Mobile
In the final article of our blog series, we’ll discuss new features coming to Salesforce1 and Lightning Experience-such as Lightning Actions-that will provide you with an easier migration path.

Why It’s Time to Break Up with JavaScript Buttons and Embrace Lightning

One of the coolest benefits in Lightning Experience is that customers and partners can add their Lightning components on the record, home, and other pages in the Salesforce application. For example, a customer might choose to add a map component to their Account record pages, or a partner might provide a component for their AppExchange app that can be added to the Home page or an Opportunity record.

The use cases are quite vast, which is why customers and partners are very excited about Lightning Experience. However, without some safeguards, the components would have access to each other’s data, shared access to the window and event structures, and access to any client side API. This could allow a partner’s component for HIPAA compliance or financial information to be accessed by another component from a different source, when they are both on the same page. I think we can agree that this is problematic, and could lead to many security and regulatory issues.

What’s Up With In-line JavaScript

JavaScript Before we discuss the safeguards that Salesforce has put in place for Lightning component security, let’s highlight some of the issues with in-line JavaScript. JavaScript is a loosely-typed programming language, supported by all modern web browsers without a plugin. It can persist data and state through cookies and storage APIs, and it can access events, URLs, and cookies through the browser. What makes JavaScript both useful and dangerous is that it has full access to the Document Object Model (DOM) and Browser Object Model (BOM).

With access to the DOM, a programmer can add, change, or delete almost anything found in an HTML or XML document. This is extremely useful in the right hands because JavaScript provides an API for working with text, dates, and regular expressions, so it is easy to add client-side functionality with JavaScript snippets that enhance the base user interface. However, this is also a big vulnerability because with Cross Site Scripting (XSS), malicious actors can gain access to the DOM or BOM via JavaScript and wreak havoc.

When a web site allows dynamic content, hackers can use XSS to inject their malicious client-side code into the web pages that are viewed by normal users. The hackers can then leverage the session and cookies from normal users to run scripts to extract data, log keystrokes, manipulate form entries, and even access APIs.

LockerService: Making Lightning Components More Secure

The good news is that Salesforce is already working on a solution to make Lightning components more secure, and restrict JavaScript’s unfettered access. The solution is LockerService, which uses various technologies and techniques that are intended to:

Prevent:

  • XSS and similar security issues
  • Unrestricted DOM access
  • Calling undocumented/private APIs

Enable:

  • Cool new features like client-side API versioning
  • Faster security review (AppExchange)
  • Better JS development practices
  • Easily updating security features and policies

So now that we know Lightning components are built to be more secure, how will you benefit from using them, and how can you recreate your JavaScript button functionality within Lightning Experience? Let’s look at how customers and partners use JavaScript buttons in Salesforce Classic.

What People Are Doing With JavaScript Buttons

We heard from many customers, some with hundreds of JavaScript buttons in their orgs; and we talked to partners about their JavaScript button use cases as well. We collated their various custom use cases into a broader set of operations. Here are the most common use cases for JavaScript buttons:

  • Use or manipulate values on a record BEFORE the save
    • Validate fields — ensure values are populated and/or meet criteria
    • Prefill values based on inputs in other fields
    • Redirect to a Visualforce page based on input values
    • Confirmation pop-up screens
  • Create records w/ pre-populated values
  • Trigger flows from Visual Workflow
  • Callouts to Salesforce or external API
  • 3rd party integration
  • Mass actions on records in a list
  • Feedback pop-up screens for users, directing methods and procedures

There are more scenarios, and some use cases that are so specific to an org that they’re impossible to categorize. In this blog series, we’ll cover existing and upcoming roadmap items that you can use to migrate JavaScript button functionality to Salesforce1 and Lightning Experience. We hope that as part of doing that, you’ll see the benefits of the alternative solutions, and ways to adapt them to your specific needs.

In our next post, we’ll cover existing solutions you can use to address some of the use cases we covered above. Specifically, we’ll look at utilizing quick actions and Apex, and examine how customers and partners have already started migrating to Lightning Experience. In addition, we’ll give you a peek into some new technology that’s going to make Javascript buttons look like day-old bread. Stay tuned!

For more information about LockerService and Lightning components, check out Lightning Components Basics on Trailhead, this awesome LockerService blog post, or the Lightning Components Developer Guide.

The Blog Team Behind This Series

Kamyar Seradjfar
Michelle Chapman-Thurber
Kevin Venkiteswaran

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS