Converting JavaScript Button for Lightning Experience – Part 1

By: Bayforce    Posted: May 30, 2017    Category: Salesforce News

Are you looking to implement Lightning Experience in your Salesforce org? Do you have a lot of custom JavaScript buttons in your org? Are your JavaScript buttons holding you back from turning on Lightning Experience for your users? We hope you enjoy Part 1 of this useful guide, below. Those curious to learn more can download the full white paper here.

JavaScript buttons are very flexible and can be developed directly in a production environment, which allows them to be deployed quickly and easily. It’s no surprise that many organizations use multiple JavaScript buttons to assist in a variety of business processes in their Salesforce orgs.

Salesforce, however, is not allowing the use of JavaScript buttons in the Lightning Experience for security reasons. JavaScript’s flexibility and ability to access the Salesforce database and browser features make it a powerful developer tool, but also leaves vulnerability for hackers to capture confidential data or inject malicious code via cross site scripting attacks.

Lightning Experience was more limited than Salesforce Classic in many ways back in the first release (Winter 16), but we’re now in the fifth release of Lightning Experience. Most new features are being released exclusively for Lightning Experience and are not available in Salesforce Classic. With each new release, incentives to switch to Lightning Experience are piling up.

If your users are clamoring to switch to Lightning Experience or if you think they could benefit from some of the new features, JavaScript buttons need not hold you back. If JavaScript buttons currently provide functions that your users depend on, you should replace them with Lightning-friendly equivalents to ease adoption of Lightning Experience. As long as you are able to devote some development energy into creating alternative solutions, this should be possible in almost every scenario, especially now that Salesforce has introduced Lightning Actions.

Here are some strategies for replacing your JavaScript buttons with Lightning-friendly alternatives.


The first step in providing alternatives for your JavaScript buttons is to inventory all of the JavaScript buttons in your Salesforce org. You can go about this in two ways.

First, you can run the Lightning Experience Readiness evaluation. You can launch the evaluation from the Lightning Experience section in the Setup menu in your Salesforce org. An automated process will check all of the features you are using in your org that are not supported or may not operate as expected in Lightning Experience and you will receive a complete report via email once the process has finished checking everything in your org. The report should highlight every JavaScript button you have in your org under the “Custom Buttons and Links –

JavaScript” section and will also provide details about the page layouts, number of profiles, and number of users for each button and a basic recommendation about how to replace the button.

Second, you can take a manual inventory of all of your JavaScript buttons by taking a look at the Buttons, Links, and Actions section of each standard and custom object in use in your Salesforce org and identify any that use OnClick JavaScript as the Content Source.

If you make a manual inventory of your JavaScript buttons, you should still take into consideration which page layouts use each JavaScript button and whether those page layouts are assigned to profiles for users who would be using Lightning Experience. When you are looking at the Detail page for a JavaScript button, you can click on the “Where is this used?” button to see which page layouts include it.

When planning alternatives to your JavaScript buttons, it’s also helpful to find out from your users whether or not they use each button, how often they use each, and how critical each button is to their work. This information can help you prioritize your JavaScript alternative release strategy.

Simple Solutions

Look for the simplest solutions first. If a JavaScript button isn’t included in any page layouts or the List View layout for the relevant object, you don’t need to replace it with an alternative.

If the button is used in a layout, but you’ve found out from your users that they never use it, you can move to Lightning Experience without providing an alternative for the button. If it does happen that some of your users need it, they can always switch back to Classic while you develop an alternative.

Some JavaScript buttons were developed many Salesforce releases ago. If your button is a few years old, there’s a chance that Salesforce has rolled out a new feature since then that can replace the function of your JavaScript button. Search Salesforce’s success site for potential out-of-the-box alternatives to your JavaScript button. It’s not very likely that you’ll find a new Salesforce feature to replace your button, but it’s worth a look because of the ease of implementation.

Here’s an example of a JavaScript button that could be replaced by a standard Salesforce feature. Say you have a JavaScript button on your Opportunity record that will open up a popup window with a search on a news aggregator for relevant stories about the Account to which the Opportunity belongs. In Lightning Experience, you can enable the News feature which will show news stories related to the associated Account record and Industry right on the Opportunity page.

Declarative Solutions

If you need to replace a JavaScript button that’s important to your users, look into whether a declarative solution will work before evaluating a programmatic solution. Declarative solutions that can replace a JavaScript button including Custom URL Buttons, VisualForce Page Buttons, and Quick Actions.

Custom URL buttons are suitable substitutes for JavaScript buttons that direct to a page on an external website or that navigate to a different record in Salesforce. For internal Salesforce links, use the URLFOR function and $Action functions or Relative Salesforce URLs (e.g. /{!Contact.Id}) rather than hard-coded URLs (e.g.{!Contact.ID}) to keep your users from getting directed out of Lightning Experience. You can update a JavaScript button to a Custom URL button by updating the Content Source for your button from OnClick JavaScript to URL, but make sure to test in a Sandbox first before you do this in your Production environment.

If your JavaScript button directs to a VisualForce page, you may be able to make a very easy update to your button to make it compatible with Lightning Experience. If your VisualForce page uses the Standard Controller for the object where the button resides, you can update your existing button to use the Visualforce Page as the Content Source, rather than OnClick JavaScript, and select the correct Visualforce Page from the dropdown list of available pages. Again, when making updates to an existing button, always test in a Sandbox first before making the change directly in your Production environment.

If your JavaScript button directs to a VisualForce page that uses a Custom Controller, you may want to look into making that page available in a Tab and re-training your users to access it through the Tab in Lightning Experience.

A very common use for JavaScript buttons is to populate a new record with values based on the values in the record where a user clicks the button. Let’s say, for example, that you have a custom object in your Salesforce org named “Project” and in your business process, when you win an Opportunity, a new associated Project record needs to be created. The new Project record needs to be linked back to the Opportunity record and will almost always share information with the Opportunity such as the Account, Primary Campaign Source, and Type. To make the new Project creation process easier for your team, you’ve built a JavaScript button on Opportunities to pull up a new Project record that automatically links back to the won Opportunity and also pre-populates fields on the new Project with information from the Opportunity like the Account, Primary Campaign Source, and Type.

This is a great use case for a Quick Action.

To create a Quick Action for this scenario, create a new Quick Action for Opportunities. Choose the “Create a Record” Action Type and choose “Project” as the Target Object.

Next you’ll want to add, to the page layout for the action,  any fields that the user should fill out when creating a new Project record, as well as any fields that should be pre-populated from information on the Opportunity.

After you have set up the page layout, you can set up Predefined Field Values.

For example, here is how a Predefined Field Value to pre-populate the Account field with the same Account as the Opportunity would look:

Now your new Project record will be automatically populated with the correct Account record when a user clicks on the New Project button on Opportunities (you’ll need to make the Quick Action available in the page layout to make the button available).

If you need more advanced pre-population, for example, if you need to pre-populate the Primary Contact from the Opportunity into the Project Sponsor field on a new Project, you may need to look into a more advanced programmatic solution.


We’re here to help. Call or email any time.